Closed
Bug 12296
Opened 25 years ago
Closed 25 years ago
Excessive string allocations (component manager)
Categories
(Core :: XPCOM, defect, P2)
Tracking
()
VERIFIED
FIXED
M11
People
(Reporter: troy, Assigned: dp)
References
()
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%
|
Assignee | |
Updated•25 years ago
|
Severity: normal → major
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: M11
|
|
Assignee | |
Comment 2•25 years ago
|
||
Thanks troy.
Summary: [PERF] Excessive string allocations (component manager) → Excessive string allocations (component manager)
Whiteboard: [Perf]
|
|
Assignee | |
Comment 4•25 years ago
|
||
rickg was going to change nsString to default to 62 chars. That would eliminate
this. Waiting for what happens there.
|
|
Assignee | |
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
|
|
Assignee | |
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
|
|
Assignee | |
Comment 5•25 years ago
|
||
Code fix verified by dp.
You need to log in
before you can comment on or make changes to this bug.
Description
•