[Gnu-arch-users] Overhead of =dirname pathcompression logic

[Ron Parker]

In another thread John Meinel posted some timings of the various
partial Windows ports of tla. I decided to reduce the number of
variables and ran a couple tests on Linux. (Actually this was done in
colinux using a minimal Debian Woody installation of my own doing.)

There are three versions of tla used on Linux and one on Windows under Cygwin.

A. tla-1.2
B. tla-1.2 with =dirname pathcompression
C. tla-1.2 with =dirname pathcompression using rx instead of chained strstrs.
D. tla-1.2 with =dirname pathcompression on Windows under Cygwin.

The first test was a simple get of a dists project.  This is very
small and the results are relatively meaningless.

A.  1.057s
B.  1.155s
C.  1.144s
D. 11.637s

The second test was a build-config of my tla-cygwin configuration.

A. 35.406s
B. 56.232s
C. 55.511s
D. 4m30.035s

This gives a fair idea of the current overhead resulting from
pathcompression versus the other Windows factors. The pathcompressed
get took ~21s or 59% longer than the regular tla. Additionally, as
John pointed out the pathcompressed get under Windows on the same
hardware was nearly an order of magnitude slower. Hmm, my old 300MHz
PII with Linux would be faster than my 2.4GHz P4 with Windows. Ouch.

Since I had it laying around I also tested pathcompression using
regular expressions instead of a chain of strstr calls just to see if
it helped the pathcompression logic at all. This only produced a 1.28%
speadup.  While this may be a good idea. It leads me to believe that
the primary slowdown from the pathcompression code is due to the
number of times it is called for each path. Whether caching or some
other mechanism is used, this can be improved.

However, without a doubt the greatest obstacles to overcome on a
Windows implementation appear to stem from Windows, NTFS and to a
lesser extent Cygwin.