RFC: fp printing speedup patch

[Paolo Carlini]

Jerry Quinn wrote:

>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.
>
Unfortunately, due to that item in the standard we *MUST*... I have
carried some preliminary tests: the speed of _M_insert_float is not
affected, since we are already doing the widen(array) call, which
involves a memcopy and we trade that for a series of essentially nop
widen(char) (this for plain chars, of course). The performance of
_M_insert_int is not really killed, is affected a bit, indeed... some
like 10-15% slower wrt the current very fast version...

>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.
>
Yes, both for ints and floats.

><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>
>
Perhaps because of what I wrote above? If you have to properly convert
all the chars anyway, in the most common case (plain chars no user
provided do_widen) many virtual function calls are still faster than
memcopy.

>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>.
>
Here, I lost you... I hope to return to this later today: in _M_insert_float
we already have the machinery, only we have to call widen(char) instead
of widen(array). Do you mean we have a latent bug unrelated to my PR of
yesterday? Which cache? It seems to me that we don't use a cache at all
for widen?!?!

Paolo.

P.S. What about those numbers for vanilla 3.4?