Page MenuHome

Performance regression of production file
Closed, ResolvedPublic

Description

Open:
/scenes/01-opening/01_050_A/01_050_A.anim.blend

In 2.79 we get 13-14 fps on my shitty computer... 12 fps should be the bare minimum (it's only one visible character in a simple scene with everything simplified)

Details

Type
Bug

Event Timeline

Just a note - if the performance woes are due to animation editors (specifically the timeline), I've got some plans already for optimising a bit there. I was going to try to work on that this week if time allows. (Specifically, my plan would also help resolve some other issues animators were having with functional side of things, by deduplicating a lot of the calculations that go into drawing the keyframes).

Francesco Siddi (fsiddi) triaged this task as Confirmed, High priority.
Francesco Siddi (fsiddi) raised the priority of this task from Confirmed, High to Needs Triage by Developer.
Francesco Siddi (fsiddi) triaged this task as Confirmed, High priority.

Measuring on my dual core laptop, I see this:

  • 23% copying meshes, particularly copying of MDeformVert (vertex groups) with many small alloc/free
  • 18% BKE_animsys_eval_driver due to slow BLI_findindex/BLI_findlink in long lists
  • 16% drawing (6% 3D viewport, 4% sequencer, 3% properties, 2% action editor, ..)
  • 16% armature deform modifier evaluation, particularly bbones
  • 15% other modifier evaluation (mesh deform, lattice, vertex group, ..)
  • 4% pose evaluation
  • 3% depsgraph

With more cores the bottlenecks will change though. I expect parallel driver/modifier/pose evaluation to be faster and single threaded copying of big meshes and drawing to be slower.

In 2.79 it looks roughly like this:

  • 65% modifier evaluation
  • 21% drawing
  • 8% pose evaluation
  • 3% copying meshes (MDeformVert data layers are mostly referenced, not duplicated)

I've brought dependency graph evaluation time to almost same figure as in 2.79 by implementing CD_REFERENCE for mesh-based modifier stack. Memory usage is still higher than it should be, likely because we're having more custom data layers in the result as we need.

Framerate went up from 4 to 6.3 on my desktop, but 2.79 figure is 12fps. So still long way to go, but need to re-investigate what is the bottleneck now.

Brecht Van Lommel (brecht) closed this task as Resolved.Jun 1 2018, 1:03 PM

One more optimization:

Performance should be at least as good as 2.7 now, and usually a few fps more.

For XInitThreads() I've created T55287.