This tasks is an summarizes where time is being spent when updating a mesh, to help us focus on areas that should be optimized.
These tests were made by timing how fast a mesh updates while transforming a single vertex of a high poly mesh.
while the exact results will differ compared to animation playback or modifier stack evaluation.
Transforming a smaller part of a larger mesh is a common enough use case that performance issues cover many other kinds of updates too.
This test was performed on the spring character, joined into a single mesh and copied 10x times (to reduce performance for measurable results).
as well as a subdivided cube (1.5m quads).
- The results are here: P2102
- The branch used for testing: rBS2e4e3adb3ed3465511eccbcdabbdcd25344b5ab2
- Tested on a release build on Linux (with some modifications for testing).
- The CPU profile set to performance to avoid unpredictable results.
- Each test disables updating some kind of data:
- use_mesh_no_tess_calc Don't recalculate tessellation/triangulating.
- use_mesh_no_normal_calc Don't recalculate normals.
- use_mesh_no_transform_update Don't update copy-on-write mesh data during transform.
- use_mesh_no_draw Skip mesh conversion and uploading to the GPU, don't populate the draw manager.
- Disabling all options is also tested to ensure there isn't any significant overhead in this case (it's clamped to 60hz on my system).
In the test results the time to update a mesh is divided between the following operations.
- ~9-14% use_mesh_no_tess_calc
- ~10-15% use_mesh_no_normal_calc
- ~15-40% use_mesh_no_transform_update
- ~30-50% use_mesh_no_draw
- The two main bottlenecks are uploading data to the GPU and copy-on write updated in edit-mode.
- Optimizing mesh conversion is a large project which needs further investigation & testing, see T87835: GPU: Mesh Drawing Performance
- Copy-on-write updates in edit-mode is redundant and as far as I can see, should be skipped entirely.
- While tessellation & normal calculation could be optimized, this doesn't seem high priority, these areas could be improved once the main bottlenecks are resolved.
- A different set of files could give fairly different results (an architectural file with many N-gons will show tessellation as taking more time for e.g).
These tests are to prioritize optimizing a common case, there is of course room for optimizing more specialized cases.
- The test files should be made publicly available, and could be expanded on.