The dfg bytecode parser only makes use of block->variablesAtTail. But currently it updates the size of variablesAtHead, valuesAtHead, valuesAtTail and intersectionOfPastValuesAtHead every single time it changes the number of Tmps and/or Locals. This happens notably whenever it inlines a function. It is not nearly as cheap as it looks, as each resizing may reallocate a Vector, requires filling the new slots with zeros, and requires moving the existing values (which are all 0) to the new Vector. This was obvious when looking at profiling of JS2: bzero + memmove are the two hottest C++ functions, and the manipulation of Operands is partly responsible. It can be easily improved: only resize block->variablesAtTail on inlining, and initialize all of the other operands at the very end of the DFGByteCodeParser.
Created attachment 433740 [details] Patch
Created attachment 433742 [details] Patch updated Changelog with perf numbers.
Created attachment 433743 [details] Patch Fix style nitpick.
<rdar://problem/81064797>
Comment on attachment 433743 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=433743&action=review r=me > Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:8971 > + block->variablesAtHead = Operands<Node*>(m_numArguments, m_numLocals, m_numTmps); > + block->valuesAtHead = Operands<AbstractValue>(m_numArguments, m_numLocals, m_numTmps); > + block->valuesAtTail = Operands<AbstractValue>(m_numArguments, m_numLocals, m_numTmps); > + block->intersectionOfPastValuesAtHead = Operands<AbstractValue>(m_numArguments, m_numLocals, m_numTmps); nit: Use the OperandsLike constructor so these lines of code don't have to change in the future if we change the Operands constructor you're invoking?
Created attachment 444624 [details] Patch Applied Saam's suggestion and rebased
Committed r286030 (244418@main): <https://commits.webkit.org/244418@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 444624 [details].
Re-opened since this is blocked by bug 233387