[cmake-developers] Configure optimization for WIN32

Philip Lowman philip at yhbt.com
Fri Apr 13 14:15:50 EDT 2007


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.

-- 
Philip Lowman



More information about the cmake-developers mailing list