GNOME Bugzilla – Bug 336699
Patch to cache omf file information
Last modified: 2006-04-02 23:15:21 UTC
This patch adds support for caching information from all the omf files in the scrollkeeper content list to ~/.gnome2/yelp.d/omfindex.xml. This reduces disk I/O and CPU usage quite a bit since yelp must otherwise open all omf files, and create a xmlXPathContext for each and parse out information. Care has been taken to recreate the cache file whenever the scrollkeeper content list is changed - that is, whenever the user rebuilds the scrollkeeper database. This is an initial patch. I still need to review it for memory leaks and clean up any debug messages before considering committing this. I would like to get some feedback regarding the patch and whether it works for people or not. Of course, I would also like to know if it provides a noticeable speed increase for people as well. This should apply cleanly against HEAD as of 2006-03-30 11:00PM MST.
Created attachment 62438 [details] [review] aforementioned patch
Created attachment 62618 [details] [review] updated patch additionally here are some benchmarks: http://www.gnome.org/~bmsmith/before.png: This is on first boot, before the cache file has been generated. It can be seen from the highlighted lines that it takes around ~5 seconds to read in every omf file. http://www.gnome.org/~bmsmith/after.png This is on first boot, after the cache file has already been generated. Here it only takes ~2 seconds to read in all the information from the cache file. After the omf files are in the kernel i/o buffers the speedup is less significant between the two cases (having a cache file vs. having to read in all the omf files). But I think the patch is still warranted as the startup time on first boot is pretty significantly improved (~3 seconds).
committed.