slow translate/rotate manipulator #55442

New Issue

Pablo Fournier · 2018-06-11T14:13:46+02:00

Pablo Fournier commented

2018-06-11 14:13:46 +02:00

2.8 version: f2e60b53z7c

autumn.279.blend

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

2.8 version: f2e60b53z7c [autumn.279.blend](https://archive.blender.org/developer/F3662649/autumn.279.blend) in 2.79 the transform, rot, scale are really fast if u compare them to the file in 2.8 also the grs

Pablo Fournier commented

2018-06-11 14:13:46 +02:00

Added subscriber: @PabloFournier

Dalai Felinto commented

2018-06-11 14:30:04 +02:00

Added subscribers: @brecht, @dfelinto

Dalai Felinto commented

2018-06-11 14:30:04 +02:00

@brecht can I interest on into profiling this?

Brecht Van Lommel self-assigned this 2018-06-11 14:38:53 +02:00

Brecht Van Lommel commented

2018-06-11 19:40:18 +02:00

Some performance comparisons (flame graph from hotspot ):

2.79
2.8

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?

Some performance comparisons (flame graph from [hotspot ](https://github.com/KDAB/hotspot)): |2.79|![perf_2.7.png](https://archive.blender.org/developer/F3665855/perf_2.7.png)| | -- | -- | |2.8|![perf_2.8.png](https://archive.blender.org/developer/F3665854/perf_2.8.png)| 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?

blender-admin commented

2018-06-11 20:00:03 +02:00

This issue was referenced by 3816502b7c

This issue was referenced by 3816502b7ca0728405d8dff8d074e3189740648a

blender-admin commented

2018-06-11 20:26:29 +02:00

This issue was referenced by 9520fc0ff7

This issue was referenced by 9520fc0ff72cb510a0991889dcbbd2010c97c16e

Brecht Van Lommel commented

2018-06-11 21:40:32 +02:00

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.

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.

blender-admin commented

2018-06-12 16:57:01 +02:00

This issue was referenced by 376bc88dc0

This issue was referenced by 376bc88dc027a8dfc5bd2f92253b17738b825c39

Brecht Van Lommel commented

2018-06-12 17:46:32 +02:00

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

Dalai Felinto commented

2018-06-12 19:16:03 +02:00

Changed status from 'Open' to: 'Resolved'

Dalai Felinto closed this issue

2018-06-12 19:16:03 +02:00

Dalai Felinto commented

2018-06-12 19:16:03 +02:00

Most prominent issue fixed by Brecht. (great work)

Further notes (from @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.

Most prominent issue fixed by Brecht. (great work) Further notes (from @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.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

slow translate/rotate manipulator #55442