Fewer keys is less data which means slightly shorter load times and slightly less work at runtime. Each timeline needs to find the key before and the key after the current animation time. The code for that is a binary search in < v4 but we've profiled it and changed to a linear search in v4. The code is:
spine-runtimes/Animation.java at 3.8

While fewer keys (and fewer timelines) is generally better, the number of keys is usually not the most important aspect to worry about. Both loading and finding the keys is fast, so making it slightly faster likely has little impact. However, deform keys can be very large and should either be avoided (use a mesh weighted to bones instead) or used very sparingly. It is likely more important to keep an eye on the number of vertex transforms.

Hi,
I know this is an older post but its along the same lines as what I was going to ask...
I'm working with some animated assets that we've gotten from another company. we're looking to optimise their meshes for use on mobile. one thing I have noticed is they're using deform keys throughout?
My question is: are weighted verts to bones better for performance or just easier to work with?

Vertex weights are easier to work with. The work needed for vertex weights and deform keys is quite different, so it's hard to compare performance. Each deform key stores a vertex for every bone with weight > 0, which can take up a lot of space for dense meshes

so much that a majority of the skeleton data could be for deform keys if care is not taken. The skeleton data is larger, more data needs to be loaded when the skeleton data is loaded, more memory is taken up by the skeleton data, and a small amount of memory is copied when the deform keys are applied (versus weights which use a small amount of CPU).

Some links to read:
Keys - Spine User Guide: Deform keys
Mesh attachments - Spine User Guide: Vertex count
Metrics view - Spine User Guide

thanks @Nate! :grinteeth: