| |||||||||||||
About precomputing hash valuesAbout precomputing hash valuesPosted Aug 6, 2006 8:59 UTC (Sun) by renox (subscriber, #23785)Parent article: Optimizing Linker Load Times
I'm a bit surprised that precomputing hash values is a gain: after all these precomputed value increase (a little) the size of the object files, so the gain of the lookup must be balanced against the increased time loading for the disk the object files.
Do the time measurements take into account the 'loading from the disk' part? Or are the object files already in memory?
(Log in to post comments)
About precomputing hash values Posted Aug 25, 2006 0:29 UTC (Fri) by bluefoxicy (guest, #25366) [Link] yeah the increase is 1-2 pages (4-8KiB) and the kernel does read-ahead caching and the read time when doing a linear read is nothing. Seek time is what kills you really; if you try to read 1 byte at a time over and over, versus read in 512 byte blocks, you'll find it takes hours to do byte by byte what takes 3 seconds to do 512 at a time (in DOS; Linux has some kind of cool read-ahead algorithm that prefetches the next few sectors).
This is a gain because the stuff winds up in adjacent memory and then CPU cache handles it much more gracefully. We also have a LOT less running back and forth to do so we don't have to read massive amounts of memory over and over and over again. (read Drepper's paper and take note of i.e. C++ common prefixes).
|
|||||||||||||