Excessive string allocations (component manager)

VERIFIED FIXED in M11

Status

()

defect
P2
major
VERIFIED FIXED
20 years ago
20 years ago

People

(Reporter: troy, Assigned: dp)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Perf], )

Reporter

Description

20 years ago
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
Reporter

Comment 1

20 years ago
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

20 years ago
Severity: normal → major
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: M11
Assignee

Comment 2

20 years ago
Thanks troy.

Updated

20 years ago
Summary: [PERF] Excessive string allocations (component manager) → Excessive string allocations (component manager)
Whiteboard: [Perf]
Assignee

Updated

20 years ago
Blocks: 7251
Assignee

Comment 3

20 years ago
*** Bug 13008 has been marked as a duplicate of this bug. ***
Assignee

Comment 4

20 years ago
rickg was going to change nsString to default to 62 chars. That would eliminate
this. Waiting for what happens there.
Assignee

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Assignee

Updated

20 years ago
Status: RESOLVED → VERIFIED
Assignee

Comment 5

20 years ago
Code fix verified by dp.

Updated

19 years ago
No longer blocks: 7251
You need to log in before you can comment on or make changes to this bug.