Closed Bug 46711 Opened 25 years ago Closed 25 years ago

nsStringKey is too big

Categories

(Core :: XPCOM, defect, P3)

Product:
Core
Component:
XPCOM
Platform:
All
Other
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: warrensomebody, Assigned: warrensomebody)

Details

(Keywords: memory-footprint, Whiteboard: [nsbeta3+])

From the footprint meeting 7/26/00: Rick discovered that nsStringKey contains an nsAutoString. Although this is a fine thing for lookup where string keys are usually stack allocated, it's a bad thing when nsStringKeys get cloned and actually stored in hashtables (they're 154 bytes each!). This is bloating *all* of our hashtables. Ideas: Make 2 classes of nsStringKey and return the smaller one from Clone. Maybe put the string key strings in an arena.
I rant about this now and then, adding myself to CC
Keywords: footprint, nsbeta3
Whiteboard: [nsbeta3+]
Fixed a couple of days ago.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
please everify
Marking Verified. Please reopen if problem reoccurs.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.