Bug 23676 – Speed up uses of reserveCapacity on new vectors by adding a new reserveInitialCapacity

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Template Framework

[Darin Adler]

In the parser, memcpy showed up on a profile, copying zero bytes when setting the initial capacity on the vector of attributes. This made me realize we could and should special-case the initial capacity setting to do less work and be more inline.

Patch forthcoming.

[Darin Adler]

Created attachment 27239 [details]
patch

[Dave Hyatt]

Comment on attachment 27239 [details]
patch

I see a couple of cases where inline capacity could have just been used instead of wasting an extra call on reserveCapacity or reserveInitialCapacity.  For example:

textBuffer.reserveInitialCapacity(cMaxSegmentSize);

Could you go through these changes and look for any that just used a fixed size constant all the time and convert them to use inline capacity instead?  I think that would make those cases more readable and help make the intent of reserveInitialCapacity more clear.

r=me

[Darin Adler]

(In reply to comment #2)
> (From update of attachment 27239 [details] [review])
> I see a couple of cases where inline capacity could have just been used instead
> of wasting an extra call on reserveCapacity or reserveInitialCapacity.  For
> example:
> 
> textBuffer.reserveInitialCapacity(cMaxSegmentSize);
> 
> Could you go through these changes and look for any that just used a fixed size
> constant all the time and convert them to use inline capacity instead?  I think
> that would make those cases more readable and help make the intent of
> reserveInitialCapacity more clear.

I don't think inline capacity is always better; I'll look at the individual cases, but note that inline capacity means that the buffer can't be transferred to another object. For example, if you're planning to use String::adopt then inline capacity won't work.

[Darin Adler]

http://trac.webkit.org/changeset/40501