[cmake-developers] dependency scanning speed

Alexander Neundorf neundorf at kde.org
Mon Sep 11 13:07:13 EDT 2006


On Monday 11 September 2006 18:05, Tanner Lovelace wrote:
> On 9/11/06, Alexander Neundorf <neundorf at kde.org> wrote:
> > On Monday 11 September 2006 15:02, Bill Hoffman wrote:
> > > At 05:46 PM 9/10/2006, Alexander Neundorf wrote:
> > > >3) it uses std::string::resize(4*1024) to preallocate space for the
> > > > strings, and then assigns always c_str() instead of the std::string
> > > > itself, since assigning the std::string apparently throws away the
> > > > preallocated memory so that the memory has to be allocated again if
> > > > the string grows (which it does often when creating the key for the
> > > > header location cache). This saves another 4 seconds.
> > >
> > > This one concerns me.   Is this always legal to do?
> >
> > Why shouldn't it ?
> >
> > std::string s1;
> > s1.resize(1024);
> > std::string s2="abc";
> > s1=s2; // -> slow, throws away the allocated memory
> > s1=s2.c_str(); //faster, also a deep copy, but doesn't throw away the
> > preallocated memory
> >
> > In the worst case it wouldn't be faster anymore.
>
> Ah.  I misunderstood.  For some reason I thought you
> were using c_str() on the left hand side of the equals.
> My bad.
>
> Yes, assigning s1=s2.c_str() is definitely always legal since, iirc,
> it will call the copy constructor that takes a c-string as input.

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.

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
-------------- next part --------------
add_executable(captest captest.cpp)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: captest.cpp
Type: text/x-c++src
Size: 433 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20060911/a6444ef3/attachment.cpp>


More information about the cmake-developers mailing list