# Fast keyframe insertion

I noticed that every time I insert a new keyframe on an object using the Python API, the insertion takes more time. Here are some timings of a keyframe insertion:

• 1st keyframe: 0.0176 ms
• 10000th keyframe: 1.0012 ms

(both only measure the insertion time of one keyframe)

Now I don't need to insert so many keyframes but this is just to show what is happening. Although it's just ~1ms here, it makes a big difference for me because I need to keyframe many objects (~10000).

So here are my questions:

• Why is this happening?
• How can I insert ~1000 keyframes to an object in an efficient way?
• Related If you have the data for frame and value. – batFINGER Jun 27 '18 at 5:50
• @batFINGER Thanks, that solved it! Maybe post a normal answer so I can accept it? – Ulwdo Jun 27 '18 at 22:05

Use foreach_set to set all fcurve data from data

Similarly to this q&a can add our data directly to an fcurve.

fc.keyframe_points.foreach_set("co",
[x for co in zip(frames, samples) for x in co])


is setting the co, the (frame, value) pair of each keyframe point

for f, s in zip(frames, samples): # zip => (f1, s1), (f2, s2) ...
fc.keyframe_points.co = (f, s)


note foreach_set requires a "flat (or one dimensional) list" eg [f1, s1, f2, s2 ...]

flat_list = [x for co in zip(frames, samples) for x in co]


Script below creates a random noise per frame for frames 1 to 250. The action and fcurve is created for location.y and assigned to the context object.

import bpy
from random import random

frames = range(1, 250)
samples = (random() for f in frames)
# some action
a = bpy.data.actions.new("SomeAction")
fc = a.fcurves.new("location", 1, "LocY")

# populate points

fc.keyframe_points.foreach_set("co",
[x for co in zip(frames, samples) for x in co])
# update
fc.update()
# assign to context ob


To tweak it up a notch, if you are not going to edit the fcurve convert it to sampled points

fc.convert_to_samples(1, 250)


Every time you add a bee keyframe, Blender has to add it to its internal list of keyframes and the larger the list becomes the more work is involved in maintaining it (allocating memory, sorting, inserting records, etc) - so it gets progressively slower.

1ms per keyframe doesn’t sound too bad to me - at least for any ‘reasonable’ number of keyframes (normally you would set a small number of keyframes and let the f-curve interpolation fill in the gaps - the whole point of keyframes really).

If you really must specify so many individual points for your animation then perhaps a Driver would suit better. A driver function could be written to take a list of distinct values - a dataset - and take some kind of ‘index’ (eg, the frame number) and return the relevant value for that object. In this way you don’t need to maintain lots of keyframes and can simply have a dataset (which could be held in a file, for example) that can be used to drive the animation.

• Thanks for this idea. I tried it and it's very fast to create all the drivers but unfortunately it's quite slow when I play the animation (~25 FPS) while the keyframes were running at ~45 FPS. My drivers' expressions are just reading the values in memory. – Ulwdo Jun 27 '18 at 20:01