Since we know that the result vector will be exactly the size of m_blocks (it is just a permutation). We should also remove the inline capacity of that vector: even most small functions will have more than 5 BB.
Created attachment 364332 [details] Patch
Comment on attachment 364332 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=364332&action=review > Source/JavaScriptCore/dfg/DFGBasicBlock.h:260 > +typedef Vector<BasicBlock*> BlockList; What’s the motivation here?
(In reply to Robin Morisset from comment #0) > We should also remove the inline capacity of that vector: even most small > functions will have more than 5 BB. Based on what data? This is actually a bit surprising to me
(In reply to Saam Barati from comment #3) > (In reply to Robin Morisset from comment #0) > > We should also remove the inline capacity of that vector: even most small > > functions will have more than 5 BB. > > Based on what data? This is actually a bit surprising to me I had just observed that while debugging some small test cases. I just tested it on JetStream2. Out of 39158 calls to blocksIn{Pre/Post}Order, only 13676 had 5 or less BasicBlocks. So the current inline capacity is only used in 1/3 of cases, and it otherwise wastes space for no reason. Here are some more numbers in case we really want an inline capacity here for some reason: - 1 BB: 7806 - <= 4 BB: 12129 - <= 8 BB: 17974 - <= 16 BB: 25612 - <= 32 BB: 32558 - <= 34 BB: 37144
> - <= 34 BB: 37144 This one should have been <= 64 BB of course.
Comment on attachment 364332 [details] Patch Clearing flags on attachment: 364332 Committed r242802: <https://trac.webkit.org/changeset/242802>
All reviewed patches have been landed. Closing bug.
<rdar://problem/48813529>