4 ms·

"The results: 18.7 seconds for bzip2, and… wait for it… 3.5 seconds for pbzip2. That’s an increase of over 80%!" File cache effect? He should cold reboot first

by malkia 14y ago

"The results: 18.7 seconds for bzip2, and… wait for it… 3.5 seconds for pbzip2. That’s an increase of over 80%!" File cache effect? He should cold reboot first (not sure how you force the file cache out on OSX/linux, on Windows I do it with SysInternals RamMap) and try in different order. It could still be faster, but he could really be measuring I/O that was done in the first case, and not in the second. It's also strange that .tar files are used, not tar.bz2 or .tbz (if such extension makes sense)

sciurus 14y ago
On linux, it's echo 1 > /proc/sys/vm/drop_caches http://linux-mm.org/Drop_Caches http://linux-mm.org/Drop_Caches
- minimax 14y ago
  Awesome tip! Thanks!
  - malkia 14y ago
    Yup. Thanks scirius! Anyone knows what's the one on OSX? (Or some multi-platform library that knows more about this stuff (Windows included))?
    - eridius 14y ago
      On OS X it's merely `purge`.
SnowLprd 14y ago
I'll do some additional testing to see if the results are affected by caching. Not sure why you're surprised that I used .tar files for the compression testing. As I mentioned in the article, most of the time I'm creating bzipped tarballs from directories of files, so it made sense to use what is, for me, a common real-world use case. Your mention of tar.bz/.tbz makes me think there's some misunderstanding, since clearly I wouldn't want to test compression of already-compressed files. But perhaps it's I who am misunderstanding your suggestion. Please feel free to enlighten me. :)
- malkia 14y ago
  Got it!