Blender 5.1 published a 304 per cent number and a 4 per cent number in the same table.
Every article I read quoted the first one.
The table is Blender's, and it is honest. The coverage is the thing I want to argue with.
What Blender actually measured
The 5.1 animation notes list three tests on one machine, a 24-thread Ryzen 9 9900X on Linux.
A 2,600-bone armature keyed for about 1,000 frames. A mesh of about one million vertices driven by shape keys. Then one real production file from Blender Studio.
The two synthetic tests flew. Action evaluation went from 32.8 fps to 74.1 at four threads, a gain of 125 per cent.
Shape keys went from 39.2 fps to 158.7 at 24 threads. That is the 304 per cent.
The production file went from 91.7 fps to 96.2 at four threads. Four per cent.
At eight threads it gained 10 per cent, at 24 threads 14 per cent. All three rows sit in the same table.
What got printed
CG Channel covered 5.1 on 17 March 2026. It quoted 2.25x to 2.3x for the armature and 2.3x to 4.0x for the shape keys.
The production row is not in the article. Linuxiac ran the same framing that day, under a headline about big speed improvements across animation.
Its summary says action evaluation more than doubles and shape keys gain over 300 per cent. Both are true. Neither is your file.
I rebuilt the same three tests
I have 5.0.1 and 5.1.1 installed on a 24-core Intel i9-14900HX. So I built the tests myself.
First, a 2,600-bone armature with 18,200 F-curves, 100 keys on each. No mesh at all.
Dependency graph time per frame, four threads: 22.4 ms in 5.0, 11.0 ms in 5.1. Blender's number holds up.
Then a million-vertex mesh with eight animated shape keys. Four threads: 35.1 ms down to 6.9 ms.
At 24 threads it went from 37.7 ms to 4.3 ms. That is nearly nine times, better than Blender claimed.
So the feature is real. Now the part nobody published.
The file that behaves like real work
A 2,600-bone armature with no mesh is not a character. So I built one that is closer.
A 120-bone rig, keyed over 1,000 frames, deforming a mesh of 1,002,001 vertices through an Armature modifier.
Evaluation at eight threads: 7.01 ms in 5.0, 3.37 ms in 5.1. Twice as fast, exactly as advertised.
Then I played it back in the viewport, solid shading, 100 frames, playback cap removed.
5.0 played at 3.42 and 3.46 fps. 5.1 played at 3.44 twice.
Nothing. The evaluation saving is 3.6 ms inside a frame that takes 290 ms.
I rebuilt the same file at 251,001 vertices to check it was not a fluke. Evaluation fell from 2.26 ms to 1.28 ms.
Playback: 11.48 fps in 5.0, 11.37 fps in 5.1. Nothing again.
Where the other 98 per cent of the frame goes
Evaluation is the part that reads your F-curves and moves your bones and vertices. That is what 5.1 made faster.
Everything after it is unchanged. The deformed mesh still has to be turned into buffers and drawn, every frame.
On my rig file that is about 287 of the 290 milliseconds. Blender improved the other three.
This is the same lesson as testing a headline feature against a pack I actually sell. The demo scene and your scene are different objects.
Check the cap before you blame the version
One thing I found by accident, and it costs nothing to fix.
With default playback sync, Blender caps playback at the scene frame rate. My armature file sat at 24 fps in both versions.
Lift the cap and the same file runs 39.5 fps in 5.0 and 69.0 fps in 5.1. The gain was there all along.
Set the scene frame rate to what you need, or switch playback sync off. Then measure.
What to do before you upgrade for speed
Open your heaviest shot in the version you have now and time 100 frames of playback.
Then look at what is in the file. Thousands of keyed bones, or dense shape keys, mean 5.1 and 5.2 will help you.
One heavy skinned mesh, or subdivision, or hair, means the win is a rounding error. Mine was zero, twice.
The habit is the same one I use for resolution: pick the number from your own scene, not from someone else's benchmark.
It is the same habit I used on AI retopology. Run the tool on your own asset before you believe the headline.
The part I want to be fair about
Blender did not overstate anything. The developers published the 4 per cent row next to the 304 per cent row, on purpose.
That is more honesty than most vendors manage. The failure happened downstream, where three rows became one.
And 5.2 is worth noting for what it does not contain. Its animation notes list no performance work at all.
So if 5.1 did nothing for your playback, 5.2 will not fix it either. Measure once, on your file, and stop reading the multiples.