Loading link-heavy pages can cause noticable periods where my machine is totally unresponsive; this happens on Tinderbox to some extent, and is very noticable with the URL above. Some simple performance analysis shows that most of this time is being spent in string allocation: here's a sample stack: ... 0CFBBC60 PPC 1D3C0A10 CSSRuleProcessor::RulesMatching(nsIPresContext*, nsIAtom*, nsIContent*, nsIStyleContext*, nsISupportsArray*)+00170 0CFBBBC0 PPC 1D3B8944 RuleHash::EnumerateAllRules(nsIAtom*, nsIAtom*, const nsVoidArray&, void (*)(nsICSSStyleRule*, void*), void*)+00278 0CFBBB20 PPC 1D3C0770 ContentEnumFunc(nsICSSStyleRule*, void*)+0004C 0CFBBAD0 PPC 1D3C0184 SelectorMatches(nsIPresContext*, nsCSSSelector*, nsIContent*, int)+01138 0CFBB700 PPC 1DDA0CEC nsWebShell::GetLinkState(const nsString&, nsLinkState&)+0006C 0CFBB650 PPC 1DE3AF18 nsCString::AssignWithConversion(const unsigned short*, int)+000E0 0CFBB5E0 PPC 1DE37520 nsStr::StrAppend(nsStr&, const nsStr&, unsigned int, int)+000A0 0CFBB580 PPC 1DE37274 nsStr::GrowCapacity(nsStr&, unsigned int)+00060 0CFBB520 PPC 1DE37174 nsStr::EnsureCapacity(nsStr&, unsigned int)+00038 0CFBB4D0 PPC 1DE388E4 nsStr::Realloc(nsStr&, unsigned int)+00058 0CFBB470 PPC 1DE38778 nsStr::Alloc(nsStr&, unsigned int)+0007C 0CFBB420 PPC 1DE164C0 nsAllocator::Alloc(unsigned int)+00064 0CFBB3E0 PPC 1DE16310 nsAllocatorImpl::Alloc(unsigned int)+00014 0CFBB3A0 PPC 1DF83C54 PR_Malloc+00014 0CFBB360 PPC 1DFEA724 malloc+0007C 0CFBB320 PPC 1DFECF3C nsLargeHeapAllocator::AllocatorMakeBlock(unsigned long)+00034

perf

sfraser: pretty sure this is a dup...lemme know if I'm wrong. *** This bug has been marked as a duplicate of 25936 ***

Well, that bug ain't the right one. Reopening so waterson can mark a dup of the correct bug.

a little dyslexic...let's try again... *** This bug has been marked as a duplicate of 25963 ***

Verified dupe, especially since the stack trace here found it's way into 25963.