Created attachment 354071 [details] [diff] [review] N_INDEX_BITS 26 Currently nsPurpleBuffer::Put spills quite a lot, which means that there are many hashtable .Put() calls, and those are slow. I've been testing with N_INDEX_BITS 26, in which case mCache has max 52 entries, and that does seem to reduce spilling quite a bit. (and dromaeo runs a bit faster) Graydon, Peter, do you know why N_INDEX_BITS 13 is used currently? Perhaps this has been discussed in some other bug, but couldn't find that.
Erm, unless matters have changed, mCache is 2-associative direct-mapped cache .. at 26 index bits, you'll have 134 million pointers in the array, which on x86 will cost you 536mb on allocation? mCache is supposed to simply accelerate the backing store; it's a stopgap measure to avoid implementing (or digging up) an actually-fast associative pointer-keyed structure like a cache-optimized digital trie. Say a judy array or the like. That's probably more what you actually want here if you're running into performance problems. Chewing up a ton of memory in the cache to avoid ever touching the backing store sounds much worse to me.
Oops, right. My mistake.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
Or not invalid, because the hash operations do show up in the profiles, but the patch is all wrong.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Attachment #354071 - Attachment is obsolete: true
So should we just mark this as dupe of bug 490695?
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago → 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 490695
You need to log in before you can comment on or make changes to this bug.