Closed Bug 12296 Opened 25 years ago Closed 25 years ago

Excessive string allocations (component manager)

Categories

(Core :: XPCOM, defect, P2)

Product:
Core
Component:
XPCOM
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: troy, Assigned: dp)

References

(
URL
)

Details

(Whiteboard: [Perf]) 

I ran Quantify to see why we take so long to display this page, and I discovered
we were creating and destroying 32,780 string buffers. It turns out that
nsComponentManager::ProgIDToCLSID() is using a nsStringKey and it seems the auto
string buffer isn't large enough so we end up allocating the buffer on the heap.

I'll file a separate bug on why ProgIDToCLSID() is being called so much, but we
need this routine to be efficient and that means no heap allocation if possible
Some additional data. There were a total of 154K calls to free() during the load
of this page, and so the 32,780 calls to free represents 21%
Severity: normal → major
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: M11
Thanks troy.
Summary: [PERF] Excessive string allocations (component manager) → Excessive string allocations (component manager)
Whiteboard: [Perf]
Blocks: 7251
*** Bug 13008 has been marked as a duplicate of this bug. ***
rickg was going to change nsString to default to 62 chars. That would eliminate
this. Waiting for what happens there.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Code fix verified by dp.
No longer blocks: 7251
You need to log in before you can comment on or make changes to this bug.