RFC: fp printing speedup patch

[Jerry Quinn]

Paolo Carlini writes:
 > Paolo Carlini wrote:
 > 
 > > Therefore, after all, I don't think the various __*_to_char should be
 > > templates parameterized on _CharT, but simple functions working on
 > > chars, perhaps including the widen(c) loop at the end.
 > 
 > ... well, of course if we want for the widen(c) loop to be *inside* the
 > various __*_to_char functions those must be template in order to pick
 > the right ctype<charT>::widen.
 > 
 > Probably it's cleaner to have the widen(c) loop part of _M_insert_int
 > and _M_indert_float.

We *REALLY* don't want to have a widen loop in the middle of
insert_int or insert_float.  That will kiss the performance gains from
caching goodbye.

I took a look at what's going on here, and aside from being unhappy
that you can override the char version of widen and not the array
version, it looks like there are two problems here.

First, as you say, the numpunct cache has to loop over the array and
call widen(char) instead of widen(array) when building the cached wide
array.

<rant-query> Why does the standard specify this less efficient
approach to widening the output?  It requires N virtual calls instead of
one call.  Ick!  Anyone know if the intent was for the array version
and char version to give the same results?</rant-query>

Second, and probably more important, the cache doesn't get rebuilt
when the new locale is created.  The numpunct<char> cache is created
for the C locale.  When the new locale is created, the numpunct<char>
cache from the C locale is referenced, rather than constructing a new
one using the new ctype<char>.

As I'm looking at this. I don't see any great way to solve this short
of removing cache reference-counting.  Even if you destroy a
pre-existing cache associated with the new facet added to the new
locale, it won't solve this problem because it is the numpunct<char>
cache that is broken rather than the ctype<char> cache (which doesn't
actually exist).

To make that work, you'd have to maintain some kind of dependency list
in a cache to know that a change to the ctype facet requires
rebuilding the numpunct facet.

I think it's simpler to avoid sharing caches between locales.  Then, a
numpunct cache will be correctly rebuilt on demand for the new facet.

Perhaps someone smarter than me can see how to preserve cache sharing
and make this work correctly.  Benjamin?

It's too late for me to assemble this patch right now.  I'll see if I
can get to it some time this week.

Jerry