Page MenuHome

Edit-Mesh Performance Overview
Confirmed, NormalPublic

Assigned To
None
Authored By
Tokens
"Love" token, awarded by fkytt."Cup of Joe" token, awarded by billreynish."Like" token, awarded by GeorgiaPacific."Love" token, awarded by gilberto_rodrigues."Pterodactyl" token, awarded by Pipeliner."Love" token, awarded by ofuscado.

Description

Motivation:

This tasks is an summarizes where time is being spent when updating a mesh, to help us focus on areas that should be optimized.

Benchmark Method:

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).

Details:

  • 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).

Results:

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

Conclusions:

  • 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.

Notes:

  • 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.

Event Timeline

Campbell Barton (campbellbarton) changed the task status from Needs Triage to Confirmed.Tue, May 4, 10:57 AM

Hello, I don´t know if this is the right place for my statement but blender is massivly slow when trying to select an object in the viewport.
The more objects are in the scene and the more poligons they have it gets slower and slower. Our typical scenes have >10000 objects and >20million polygons. That is not extreme.
We use a very old 3D-program that was not updated since 2012 to select and shade all our objects in the scene, because in Blender it is not possible. In Blender you wait 5-10sec after clicking on an object in the viewport until it gets selected.
In the other packages selection is instantly. This Program can handle more than 100million polygons and instant selection with ease.
I hope this behavior could be solved when you now try to improve the edit-mesh performance!
Thanks