Page MenuHome

slow translate/rotate manipulator
Closed, ResolvedPublic


2.8 version: f2e60b53z7c

in 2.79 the transform, rot, scale are really fast if u compare them to the file in 2.8 also the grs

Event Timeline

Brecht Van Lommel (brecht) triaged this task as Confirmed, Medium priority.EditedJun 11 2018, 7:40 PM

Some performance comparisons (flame graph from hotspot):


In 2.79:

  • 75% modifier evaluation (mainly armature)
  • 10% drawing
  • 5% pose evaluation
  • 5% drivers

In 2.8:

  • 30% modifier evaluation
  • 15% pose evaluation
  • 10% pose copy-on-write
  • 10% driver and animation eval
  • 5% armature copy-on-write
  • 5% drawing

From what I can tell threads are spending more time waiting, and these single-threaded operations are showing up in the profile:

  • Python driver expressions are being recompiled every time, while previously they were cached on the datablocks. This is because with COW the data is lost whenever the data is copied again. We could cache these on the original datablock, or in a separate hash somewhere.
  • The copying of poses and armatures for COW. For poses BLI_findstring in BKE_pose_channel_verify takes up half the time. A hash could speed this up, if it is kept up-to-date while copying. Further, I don't think it's necessary to make a copy of the armature datablock for every update, since we are editing the pose on the object?

With the two committed fixes it's already noticeably faster, but I did not measure it exactly.

There's still 5-10% overhead of datablock copying, but the faster 4x4 matrix invert might gain that back.

The armature datablock copy is due to deg_graph_id_tag_legacy_compat(), which is supposed to be temporary until more code is converted to use the new recalc flags.

There was a further problem where performance of manipulators degrades over time. This should be fixed as well now.

Dalai Felinto (dfelinto) closed this task as Resolved.Jun 12 2018, 7:16 PM

Most prominent issue fixed by Brecht. (great work)

Further notes (from @Brecht Van Lommel (brecht)) about that:

It's still a bit slower than before due to copy-on-write overhead.
Half of it will be fixed once we go more granular for depsgraph tagging (armatures).
The other half (pose) probably has no solution and we might just have to accept it. Although something like multithreading the pose copy could work.