The data structures we currently use to represent CSS selectors use a lot of memory because: * we store them in lots of separate allocations, with pointers connecting them * the base nsCSSSelector class has a member variable for each thing it *might* have As I proposed in bug 691189 comment 6 and elsewhere in the past, we should consider, without reference to the current code, how one ought to implement a space-efficient representation of CSS selectors such that the things we need to do with them are still fast (and hopefully faster). My initial inclination would be to have a fused-allocation structure with parts of the fused allocation indicating what's coming next, and perhaps a few things that make it easy to skip around (in particular, the size of each compound selector (in selectors4 terminology) / sequence of simple selectors (in css3-selectors terminology) / simple selector (in CSS1/CSS2.1 terminology)). This would be somewhat like nsCSSCompressedDataBlock, particularly back when data blocks stored more than one type (prior to bug 576044). This should probably wait until after bug 661746 and bug 631527 land.
Of the allocations in bug 551477 comment 48, this bug is related to: > HEAPPROF 16701: objects/bytes: 177885/18446274 in CH, > 155018/13662436 in CH-tagged > > RANK OBJECTS/BYTES ALLOCATED BY > > 1 19084 / 1374048 nsCSSSelector::nsCSSSelector() > 12 10306 / 247344 nsCSSSelectorList::nsCSSSelectorList() > 35 1156 / 36992 nsPseudoClassList::nsPseudoClassList(nsIAtom*, > nsCSSPseudoClasses::Type) and probably some additional ones not included in that comment.
Random data-point: on 32-bit, sizeof(nsCSSSelector) is 40 bytes, which jemalloc rounds up to 48. On 64-bit, it's 72 bytes, which jemalloc rounds up to 80.
You need to log in before you can comment on or make changes to this bug.