[cmake-developers] dependency scanning speed

[Alexander Neundorf]

On Tuesday 12 September 2006 20:17, you wrote:
> Alexander Neundorf wrote:
> > On Monday 11 September 2006 19:24, Tanner Lovelace wrote:
> >> On 9/11/06, Alexander Neundorf <neundorf at kde.org> wrote:
> >>> Can you please compile and run the attached file with gcc 4.0 and if
> >>> possible gcc 4.1 and post the output here ?
> >>> Maybe the capacity-behaviour is already "fixed" in current gcc.
> >>
> >> Actually, I believe it's expected behavior.  Assigning a string to
> >> another string doesn't just copy the character contents to it, but also
> >> copies all of the internals too.
> >
> > That's what I thought too, and I also had a quick look at the standard,
> > but didn't see anything mentioned.
>
> The standard just specifies the interface and leaves details like this
> implementation defined.  When you do
>
>   lhs = rhs; // #1
>
> the implementation is probably using a copy-on-write optimization which
> throws out the lhs memory and actually references the rhs data directly.
>  When either lhs or rhs is later modified the copy occurs at that point.

Yes.

> When you do
>
>   lhs = rhs.c_str(); // #2
>
> the lhs has to use its own data anyway so the implementation doesn't
> bother reallocating.

Yes.

> If you do
>
>   lhs.assign(rhs) // #3
>
> I bet you will get behavior at least as fast as #2 because

I tried lhs.assign(const char*, unsigned int length); 
but didn't notice any improvement, it was even a bit slower than the 
operator=(const char*), but this was probably noise.

Here is more info:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29037


Bye
Alex
-- 
Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de
Home: neundorf AT kde.org                - http://www.kde.org
      alex AT neundorf.net               - http://www.neundorf.net