I was of course wrong. I started to write a parser to read the content of the icon cache. My curiosity was raised when I started to dump what was storead and where... and I discovered that the chained elements of the hash table are spread accross the cache, near of their related group of icon. I mean group as each chain element is not related to a specific icon but to a set of related icons that have the same name but stored in a different directory.
On one side, this is not a big deal as whenever you have a match between the icon name and the chain element, the page where the icon is stored is likely to have been loaded. On the other side...
- If the chain element you are comparing to is not the one related to the icon you are looking for, you loaded a block into memory for nothing.
- The current layout assume the same icons for different directory are grouped together in the cache file. This assumptions is no longer true if we decide to reorder the icons in the cache file based on their usage...
The first point is supporting my idea that chain elements should be reordered based on their access frequency. I computed for the default gnome theme the values for "How many chains containx x elements?"
|Length of Chains||# of chains|
This means that in the worst case, you may end-up accessing 7 pages that you should not have. For one icon that's a lot of wasted disk access.