Re: [v3] libstdc++/16612

[Paolo Carlini <pcarlini at suse dot de>]

Hi again,

> Have any other ideas? Other than partial specializations of std::string
> I'm fresh out. If you look through bugzilla, there seem to be two
> approaches: the one outlined here and the mock-up in p.10040721-3.
> Honestly, I think this one is better.
>
> Right now I think this plus partial specialization is the best approach.
>
> Thoughts?
First a preliminary observation: more than two years ago, when I started 
working
on the library, I fixed a bug in basic_string::reserve, as you remember. 
Then,
always with Nathan's help, I kept on improving to my best basic_string, both
from the correctness and the performance points of view. More recently, 
people
started calling me "basic_string maintainer": I'm proud of that, since I 
like
strings and all the algorithmic issues involved.

If, in a few months, I haven't fixed this specific problem, is not because I
don't care, or because I definitely prefer working on other things: it's 
because
is *tough*, *very* tough. Probably, everything considered (in 
particular, pending
work on a new flexible implementation for v7), I was even tempted to 
close the
PR as WONTFIX, at least for 3.4/4.0.

As Nathan says, after so many years, it's the first time that someone 
points out
this kind of problem: respect for all the other satisfied users means 
that we must
be very careful about performance regressions in the common case. As my 
testcase
shows, we are risking a 2x slow-down on the most fundamental and supposedly
fast operation: character access. Benjamin, we do *not* want it. Nobody 
really
wants it, I'm 100% sure. On modern processors, characterized by long 
pipelines,
every conditional kills performance and the same 2x slow-down I have 
measured
on 64-bit Opterons, this is a generic extremely serious issue, indeed. 
Every time
we add a conditional we have to benchmark, in my opinion.

Nathan suggests avoiding sharing the empty rep: I think we should 
explore that,
is a  promising idea, indeed. Thanks Nathan! If that doesn't work out, 
everything
considered, I like better (as a *temporary* solution, indeed, only to 
allow testing
of the shared allocator and answer submitter's needs) your original idea 
in the
audit trail. But let's try avoiding completely a shared empty rep, 
first. I can
help on this whenever you want, the whole next week, f.i., let's keep in 
touch
privately too, as usual.

Paolo.