Follow-up Comment #2, bug #23542 (project findutils): Obviously from the timing information you gave, we can see that almost all the time is used up in I/O wait rather than user or system CPU time.
Tools that are useful for finding out why your disk I/O are slow include iostat and strace. You can use strace for this task like this: strace -c find /home/xxx/www -newer /home/xxx/flag > /dev/null The result is a list of system calls with a summary of how much time is spent in each. You should read the strace documentation to understand how to understand the output. Although you mention that your filesystems are ext3, you don't indicate whether the "dir_index" feature is both enabled and in use (because you've run e2fsck -D). I assume at this point that this will make a huge difference. As the anonymous poster said, it's likely that the differences in runtime are affected by cache warmth but I would also guess that somethign else is going on since you didn't indicate there's a pattern to the run-time. The fundutils source tarball also builds by default a binary called "oldfind" which uses a different algorithm. It might be worth comparing the runtimes of the two implementations. Lastly a point unrelated to findutils. If you are serving static web content out of /home/xxx/www, you have a very poor configuration. Most Unix filesystems deal badly with very large directories, and you would be wise to avoid such an arangement. One wayt of dealing with this issue is to separate the URI view of your website from the filesystem layout of the HTML content by using URL rewriting. This technique will also allow you to maintain URI stability; see http://www.w3.org/Provider/Style/URI for more information. _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?23542> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/
