[cmake-developers] Configure optimization for WIN32
Bill Hoffman
bill.hoffman at kitware.com
Fri Apr 13 14:51:40 EDT 2007
Philip Lowman wrote:
> Hello all,
>
> I'm new to the developers list. We use CMake at work as our build
> system but we noticed that when configuring on Windows with the source
> code on a network share that it was much slower than on the hard drive
> so I set off to optimize this case.
>
> After trying to optimize several areas I thought the slowness was coming
> from involving network I/O and failing to find it, I read an article on
> profiling and tried a technique I hadn't thought of before, basically
> pausing the program several times with the debugger and seeing what's
> executing. This worked wonders and after 4 out of 5 pauses pointed to a
> single line of code, I had quickly deduced the real culprit of the slowness.
>
> The culprit is in Source/kwsys/SystemTools.cxx in the method
> PortableGetLongPathName which is called from GetActualCaseForPath
>
> PortableGetLongPathName appears to take a long time when it executes a
> function pointer and calls the win32 GetLongFilePath() function on
> networked files. I'm assuming that the slowness here is purely due to
> network latency and the number of times this function is called. I
> logically then started looking at the caller of this function which is
> GetActualCaseForPath()
>
> On Windows XP this function takes a long filename and shortens it to an
> MS-DOS compatible 8 character name and then turns right around and
> converts it back to a long filename. It does this because this has a
> side effect of correcting the case of the filename if it was specified
> incorrectly.
>
> On a local hard drive this case correction is very fast but over the
> network it is extremely slow. Just for a random benchmark here,
> removing the case correction improved our configure time by 350-400% in
> my tests reducing it to around 6 seconds.
>
> So I was wondering, is obtaining the proper case even needed on WIN32?
> I mean it's cool that if the user specifies a file with the wrong case
> to turn around and fix it for them but can't the users of this function
> be responsible for specifying the proper case to begin with? It's that
> way on all other platforms so it seems silly to add this for WIN32
> especially if it causes performance problems.
>
>
I can not remember the exact case, but I think I had to add that to get
around some problem.
I don't think it was just a matter of fixing what the user entered.
GetActualCaseForPath is only called twice in the cmake source tree as
far as I can tell.
It is in cmOrderLinkDirectories.cxx, but in this case it is only called
for the library paths used.
The other place is CollapseFullPath in SystemTools.cxx. If you comment
out the one
call in CollapseFullPath do you get the same speed up?
-Bill
More information about the cmake-developers
mailing list