[v3] pr 8761 and 7076, caching bits
Benjamin Kosnik
bkoz@redhat.com
Tue Feb 18 05:44:00 GMT 2003
> > %rm foo.txt ; time gcc-2.96.exe
> > 10.130u 0.730s 0:11.70 92.8% 0+0k 0+0io 135pf+0w
> >
> > %rm foo.txt ; time 20030215-round-4.exe
> > 8.920u 0.610s 0:18.14 52.5% 0+0k 0+0io 108pf+0w
>
>How does it compare to gcc 2.95 for you? I tried out this version and
>it is about 0.1s slower than what I had posted. I'm not sure why. I
>think it has to do with the static initialization of
>locale_cache<char> and locale_cache<wchar_t> that are no longer there.
>The interface vs. _M_populate I think is an improvement.
I don't have 2.95 on this machine, sorry. I don't expect a difference.
I'm not especially worried about .1s, especially since the the previous
specialization was wrong.... can't assume the char specialization is the
"C" locale.
>A quibble:
>
>Since we've added _S_end to __num_base, we should use it here in place
>of _S_udigits_end. I missed this previously:
>
>+ // A list of valid numeric literals: for the standard "C" locale, this
>+ // is "-+xX0123456789abcdef0123456789ABCDEF". This array contains the
>+ // chars after having been passed through the current locale's
>+ // ctype<_CharT>.widen().
>+ _CharT _M_literals[__num_base::_S_udigits_end];
Done.
> > Some questions remain.
>
>What questions are those?
Denoted with XXX... fixed now. There was an unnoticed issue
with copyfmt and locales in general that was illuminated with the cache.
I also wanted to profile with valgrind, and was having some problems
given the bleeding-edge platform I was testing on.
> > Also, the thought of putting this in as a non-virtualized layer of the
> > locale class itself bears investigation. That approach might fit into
> > the confines of the 3.2 ABI. That or a second patch are things I'd like
> > to look into.
>
>How do you see this working? What is the second patch you have in
>mind?
Well, I was kind of vague, sorry. I don't think the current approach will get
much better than the attached patch. I think it should go in...
It would be nice to profile all the facets, and see what needs to be
cached: that can happen in a piecemeal fashion, but should happen before
3.4 is released as I'm worried about the extensibility of
__locale_cache. There's a difference between versioning a new
non-virtual member function, or static data member, and having each new
cached bit change the size of a class. Granted, __locale_cache is not
exported, and is not directly a member of exported classes (just the
auto_ptr<__locale_cache_base*>, but ..... just wondering if there was a
better way.
Anyway. I see __locale_cache as a de-virtualized locale class for io. It
seems sad that, in essence, using std::locale will require caching. As
part of that, I was wondering if there was a way to incorporate the
cache itself into the locale class itself.
if (has_cache<ctype>(loc))
do_fast()
else
use_locale<ctype>(loc).do_slow()
I don't see a way to have quick access to cached data, and
simultaneously make it arbitrarily extensible. Would be cool though.
-benjamin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p.20030217
Type: application/octet-stream
Size: 25882 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20030218/69ba5555/attachment.obj>
More information about the Libstdc++
mailing list