Possible over-optimization

[jeremyckahn]

I uploaded this video detailing the performance improvements to Shifty in 2.14.0. At the linked point in the video, I explain the reused variables used in Shifty's private helpers. For instance, here:

shifty/src/tweenable.js

Lines 54 to 98 in af71d52

	export const tweenProps = ((
	easedPosition,
	easingFn,
	easingObjectProp,
	hasOneEase,
	key,
	normalizedPosition,
	start
	) => (
	forPosition,
	currentState,
	originalState,
	targetState,
	duration,
	timestamp,
	easing
	) => {
	normalizedPosition =
	forPosition < timestamp ? 0 : (forPosition - timestamp) / duration
	easingFn = null
	hasOneEase = false
	if (easing && easing.call) {
	hasOneEase = true
	easedPosition = easing(normalizedPosition)
	}
	for (key in currentState) {
	if (!hasOneEase) {
	easingObjectProp = easing[key]
	easingFn = easingObjectProp.call
	? easingObjectProp
	: formulas[easingObjectProp]
	easedPosition = easingFn(normalizedPosition)
	}
	start = originalState[key]
	currentState[key] = start + (targetState[key] - start) * easedPosition
	}
	return currentState
	})()

This is an admittedly weird way to write JavaScript, but the basic idea is that these functions' variables are being reused from invocation to invocation. I assumed this would be faster, as the variables are being reused rather than redeclared many times in a tick. However, it's not so cut and dry. Take a look at this Gist that benchmarks this technique, and its results:

Regular function:  Completed 10 iterations in 0ms
Closured function: Completed 10 iterations in 0ms

Regular function:  Completed 100 iterations in 0ms
Closured function: Completed 100 iterations in 0ms

Regular function:  Completed 10000 iterations in 3ms
Closured function: Completed 10000 iterations in 2ms

Regular function:  Completed 1000000 iterations in 27ms
Closured function: Completed 1000000 iterations in 34ms

Regular function:  Completed 100000000 iterations in 1758ms
Closured function: Completed 100000000 iterations in 3403ms

The "Closured" function (the one with the reused variables) is slightly faster for fewer iterations, but starts to become slower for greater numbers of them. This is the opposite of what I expected.

I'll experiment a bit with which approach yields better results in Shifty. If it seems that the standard form is faster, I'll switch to that as the code would be far more maintainable. I'll update this thread with what I learn!

[jeremyckahn]

Behold, science!

I made an experimental branch to explore this idea a bit. Here's the relevant commit: db7c646?w=1

And here are benchmarks for the before each approach:

• 2.14.1 with reused variables
• 2.14.1 experimental build with redeclared variables

And here's how the memory utilization compares (experimental build is on the right):

The version with re-declared variables is trivially more efficient, both with with CPU and memory usage. The code is also far more readable and maintainable. Indeed, I got too clever and over-optimized here. But now we have the metrics to prove it!

I'll release the improved version as 2.14.2 shortly. 🙂

[jeremyckahn]

2.14.2 has been shipped!

[4ian]

Hey @jeremyckahn I hope it's ok to revive this discussion now - just to tell you thank you for posting this and your observations/benchmarks! Very useful to understand this kind of over optimizations and how they scale/don't scale.
Seems that JS engines are working well with "traditional" variables declared on the stack, that's good to know! :)

Thanks again for your work on Shifty and on these kind of optimisations!

[jeremyckahn]

I'm glad to hear you got something out of this exploration as well, @4ian! It was fun to go super deep on performance analysis like this. I don't often get to do that! 😄