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.
Created attachment 27239 [details] patch
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
(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.
http://trac.webkit.org/changeset/40501