Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Multiple assignment has too much overhead #2916
Multiple assignment has taken a perf hit in 9k compared to 1.7, and there's other opportunities to go beyond 1.7.
The main issue is that it's always producing the RHS array for some forms, and simply not eliminating it for other forms.
This case should optimize to simple moves. I believe it doesn't because DCE is not running:
a, b, c = d, e, f
This case, where ary is already an array, should not have to dup the array. I believe we dup it now preemptively because it may be used as the return value of the expression. However this won't go away with DCE because ary is opaque (assume it's opaque below).
ary = [1,2,3] ... a, b, c = *ary
These cases affect performance on e.g. https://github.com/YorickPeterse/oga because it uses masgn in the second way above. Many other libraries use these forms too.
I made a patch for this simple form a week or two ago and it did optimize well but at that point we(subbu) noticed LocalOptimizationPass was no longer executing at all. With LOP re-enabled it was able to eliminate the array. My optimization was very specific to Masgn and LOP was optimizing this generically. The neat thing about the patch is it reduced specialized instrs to a series of Copy(). The unneat thing is that patch + LOP decreased perf by 10x (don't know why).
I will try and get a clean patch for my change. I recently squashed masgn and masgn19 to one class so this is conflicting atm.