Lucas, do you have an idea for bad the current code is in practice? You mentioned it was in a hot code path.

+alan does this sound reasonable? As far as I can tell there's no reason we have to keep the arbitrary list of lists structure as long as we correctly determine the structures are identical and correctly interpret the flat double list.

I'm looking at the Preact Speedometer benchmark, and InterpolableList::Clone is ~1.7% of the total time. More than half of this time is spent on malloc.

Here's a profile capture of Preact (over 1000 runs), showing the allocation cost of InterpolableList.

Deleted: profile_interpolablelist.png 31.4 KB

	profile_interpolablelist.png 31.4 KB View Download

I think the amount of malloc involved in the animation code path is excessive and would be pleased to see it reduced with something like this.

The tree structure of an InterpolableValue is still needed for additive animations though as there's no guarantee that the shapes are the same there.
Example: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/animation/ListInterpolationFunctions.cpp?type=cs&sq=package:chromium&l=254

Wise or not, I starting looking at this Friday evening. I'm far enough along that I should probably assign this bug to myself to avoid duplicate work.

(It's possible that something even more efficient that could get SIMD support etc could be done in the longer term, but just dropping the allocation by storing numbers inline should help.)

Adding the blocking label so we can keep track of the speedometer improvements.