Bryan: Are you sure about that? Explain this:
bash-4.1$ time java LineReverse /usr/share/dict/words > /dev/null real 0m1.413s user 0m1.634s sys 0m0.270s bash-4.1$ time ./strrev /usr/share/dict/words > /dev/null real 0m0.055s user 0m0.052s sys 0m0.003s bash-4.1$ time java LineReverse words3 > /dev/null real 0m3.966s user 0m3.570s sys 0m0.953s bash-4.1$ time ./strrev words3 > /dev/null real 0m0.171s user 0m0.162s sys 0m0.009s bash-4.1$ time java LineReverse words6 > /dev/null real 0m7.151s user 0m6.157s sys 0m1.535s bash-4.1$ time ./strrev words6 > /dev/null real 0m0.326s user 0m0.312s sys 0m0.014s words3 is the original file concatenated 3 times, words6 is 6 times. In case it is not obvious - if the problem was just the JIT overhead, we would not have seen this kind of increase in execution time from the Java version as the file got bigger. I do accepts Joshua's objection to the use of mmap() - it is cheating somewhat. mmap() is not robust - file I/O error will result in a coredump. What I would really like to see from the Linux kernel is to have a special signal being emitted instead of SIGSEGV when the page fault is caused by file I/O of an mmap()-red region. -- Sasha Pachev Fast Running Blog. http://fastrunningblog.com Run. Blog. Improve. Repeat. /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
