On Sun, Nov 09, 2003, Oleg Kobets wrote about "Re: Redhat 9 slowness - continued":There was a profiling tool for Solaris kernel modules that was nonintrusive to the applicaion's code. The way it worked was by bombarding the kernel with interrupts, and checking the stack backtrace each time to see what it interrupted the kernel in doing. This way, it gave a statistical analysis of where the CPU was spending it's time.
Oh, well.
But the question remains, why is it slower ?
Continuing the Redhat 9 saga:
I previously thought that the slowdown had something to do with the dynamic linking slowdown. I no longer think so - I think the /lib/tls/* libraries are slower in doing some operation than /lib/i686/* libraries are.
I now ran hspell on a very big corpus of about 3 million Hebrew words, on my Pentium 1500 running Redhat 9. With the default /lib/tls libraries, hspell took 8 CPU seconds (user time). With LD_LIBRARY_PATH=/lib/i686, the time is down to 4.5 seconds!!
The 3.5 second difference of course cannot be attributed to slow dynamic linking - it's the /lib/tls that suck. My guess is that some common C function that hspell uses, perhaps even the stdio, strlen(), or who knows what, is much slower in the tls version. I wonder what is that slow-poke function that I should avoid... I can't even profile this problem, because there is only one variant of the profiling libraries (glibc-profile doesn't appear to contain "tls" and "i686" variants).
Another possibility is that the tls version wasn't optimized for 686 while the i686 libraries were - though I doubt this can explain the almost half- speed performance I'm seeing.
I wonder whether such a tool exists for Linux userspace as well.
Shachar
-- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
