Re: [v3] pr 8761 and 7076, caching bits

[Benjamin Kosnik <bkoz at redhat dot com>]

> > %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

Attachment: p.20030217
Description: Binary data