I quantified the style system after hyatt's landing of the redesigned system and noticed that 42% of the time in CSSRuleProcessor::RulesMatching and 3% overall is spent in the nsAutoVoidArray constructor. The reason this is expensive is because it clears the full array with memset. I don't see the reason for this. It seems like an awful easy fix to just remove the memset. All the figures are from the colour table stress case

It does seem kind of weird, because looking at the code, it appears to be setting none of them to zero (mImpl->mCount is zero by the time ::memset is called). From what it looks like to me, I would say we could remove that line, since it currently does nothing.

You are right. So that line is without any meaning at all (yet it showes on profiles). Do you want a patch? :-)

Sure, if you have a patch, post it and I will r= it. I believe that the tree will be closed except for crasher bugs for a bit, bit I will check it in when it does open. Thanks.

I attached the patch. I have run with it for a week without noticing anything bad.

r=kandrot. sr=? a=? Does it look to be any faster with this patch? Did the times drop as predicted? Just curious.

sr=waterson

a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)

I have checked in the change. Thanks. (though if you have the performance numbers, please post them to this bug, thanks)

The numbers I have is from Quantify in the table stress case. nsAutoVoidArray::nsAutoVoidArray 30000 calls Before: F+D 71 ms (1.47% of total time) After: F+d 1 ms (0.02% of total time)

Good lord, is that milliseconds? (I'm guessing you meant to write 71us...)

No, Quantify says 70907,32 us (microseconds) 1.47% of Focus. Then I'm not sure if Quantify is right since the memset is timed rather than profiled by instruction count. The After time is 977,86 us. I'm marking this VERIFIED since the memset is very gone now (code inspection).