Closed Bug 520671 Opened 13 years ago Closed 10 years ago

nsTArray is free-happy


(Core :: XPCOM, defect)

Not set



Tracking Status
blocking2.0 --- -


(Reporter: sicking, Unassigned)


(Blocks 2 open bugs)


(Keywords: perf, student-project, Whiteboard: [mentor=jlebar])

Don't really know who to cc on this..

Spun off from bug 520621 comment 4. nsTArray is way too happy to free the memory it's holding, which can cause a fair amount of memory churn. It'd be interesting to see data on what the effects would be of simply removing the call from ShiftData to ShrinkCapacity would be.
Blocks: 522967
blocking2.0: --- → ?
Keywords: perf
I don't think this is a blocker, but it's something we should experiment with.

Jst, this is the issue I talked about in the perfkill meeting yesterday. Forgot that I had filed this.
blocking2.0: ? → -
Whiteboard: [MemShrink]
Although we may be able to improve TArray in this respect, I doubt these changes would have a measurable effect on memory usage.

I presume the ShrinkCapacity call in question here is

nsTArray::ShiftData() {
  if (mHdr->mLength == 0) {
    ShrinkCapacity(elemSize, elemAlign);

Note that naively removing these two lines would mean that nsTArray::Clear() would not free any memory, which is no good.  (Clear() calls RemoveElementsAt() calls ShiftData() calls ShrinkCapacity().)
Whiteboard: [MemShrink] → [MemShrink][mentor=jlebar]
Whiteboard: [MemShrink][mentor=jlebar] → [mentor=jlebar]
I'd like to see careful measurements made before making this kind of change.  In bug 715770 I'm in the process of undoing some "hold onto freed blocks in case they can be reused" code precisely because this kind of thing often doesn't do much, because heap allocators like jemalloc do that kind of thing themselves.
I'm really doubtful that there are serious gains to be had here.  Let's just close this.
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.