470684 - Investigate if nsPurpleBuffer::Put could be optimized

Status: RESOLVED DUPLICATE of bug 490695

(Core :: XPCOM, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

Attachment: 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.

Comment 1

[Graydon Hoare :graydon]

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.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Oops, right. My mistake.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Or not invalid, because the hash operations do show up in the profiles, but
the patch is all wrong.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This should be addressed by bug 490695.

Comment 5

[Peter Van der Beken [:peterv]]

So should we just mark this as dupe of bug 490695?