Page MenuHome

BMesh: small perf fixes
Closed, ArchivedPublicPATCH

Description

BMEMSET sets memory byte-by-byte, and if size is an expression involving pointers (as it is for the mempool) the macro re-evaluates the expression each iteration (because the compiler can't determine that writing a byte of 0 didn't change the value of the size expression). Factored this out to a local.

The mesh is being copied (into em->emcopy) and the copy gets tesselated before each tool runs, but most of the time the copy is just freed after the tool completes successfully, it's only used when an error occurred, to restore the original mesh. The tesselation isn't necessary unless an error actually *does* occur, so this change moves the tesselation of the copy to that point.

Event Timeline

Please note that while these changes *do* give me something like 30% perf improvement on Win64/MSVC for scenarios like separating loose parts of 6 objects with 1.5 million faces (heavy face-create scenarios), both of these perf pain points (BMEMSET and the em->emcopy) were discussed last night on #blendercoders between Briggs, Ideasman, and myself, and there is a good chance they will just go away eventually.

Still trying to get these out of my enlistment to clean things up so either it will get committed or it will get rejected and I'll just revert it and forget about it. I won't take it personally =D

I committed this in BMesh r40264

Andrew Wiggin (ender79) changed the task status from Unknown Status to Unknown Status.Sep 17 2011, 3:53 PM