From: Hartmut Birr
Sometimes ago there has exist a profiling function which has used the hash table functions from ex\hashtable.c. The problem is that the hash table functions uses the splay tree functions which are broken. In my local sources I had replaced the splay tree by a simple double linked list. I've never see such speed problems. This was at the begining of 2003. I had used the profiling for compiling ros on ros.
Yes, sounds like the same profiling stuff I'm using. I already talked to Casper (original author of the hashtable stuff) about the splay tree.
Note that my profiling experiment is sort of a worst-case scenario. I'm using a 300 MHz machine which is not exactly roaring with power. I have a foreground thread running the functions I want to profile, which is completely CPU bound. So basically the foreground and profile-conversion thread each get 50% of the CPU. Timing was done by calling KeQueryTickCount() at beginning and end of the conversion and printing the difference.
Compiling ros on ros might be a little different, as that might not be CPU bound. Throw in a faster CPU and the conversion might go a lot faster.
Gé van Geldorp.