[Bf-committers] Python + Many Objects = slow!

[Daniel Dunbar]

Oh my gentle jesus.

/me wanders over to EXPP_interface.c

I don't mean to insult anyone, but,
BWAHAHAHAHAHAHA,
wtf?!!!!!

Note that:
object = GetObjectByName(GetIdName(id))
is equivalent to
object = id

Although, the second one is a tad bit faster.
(Ok, they aren't exactly equivalent, but under
the only constraints that this function is called
I think they are).

The same goes for
lamp = GetLampByName(GetIdName(id))
and all the other versions.

I don't know if I want to know the explanation behind
this code. I might only note that naming inconspicuous
functions to hide their O(N) behavior is a bad practice.
GetObjectByName should really be called, 
DoAnObscenelyLongSearchInContrastToWhatShouldReallyBeNecessaryToFindAnObjectByName.

Wheee!

--- Chris Want <cwant@ualberta.ca> wrote:
> 
> Bear with me, I don't usually write stuff this long, but
> I would just like to share some surprising results from a bit
> of profiling...
> 
> This weekend it was pointed out to me that some changes
> I had made to the armature/action/nla code had slowed down the
> rendering of animations in blender 2.33 for scenes with many objects
> (whether the scene had armatures or not). These slowdowns occur both
> when pressing the 'ANIM' button or through Alt-A.
> 
> Indeed, a simple test file with  4096 planes, one lamp, and one
> camera yields the following render times in various versions
> of blender:
> 
> blender-2.23: Saved: /tmp/render/0004 Time: 00:00.79
> blender-2.25: Saved: /tmp/render/0004 Time: 00:00.86
> blender-2.26: Saved: /tmp/render/0005 Time: 00:01.10
> blender-2.27: Saved: /tmp/render/0005 Time: 00:01.10
> blender-2.29: Saved: /tmp/render/0001 Time: 00:02.03
> blender-2.31: Saved: /tmp/render/0003 Time: 00:01.88
> blender-2.32: Saved: /tmp/render/0001 Time: 00:04.87
> blender-2.33: Saved: /tmp/render/0001 Time: 00:07.61
> 
> Ton and Rob hinted at where the slowdown was -- a dumb piece of
> slow code that should have only been run for armatures, but was
> instead being run for every object in the scene.
> 
> Limiting the execution of the code to only armatures yields
> a really nice speedup for this scene:
> 
> Current CVS:  Saved: /tmp/render/0001 Time: 00:01.87
> 
> By 'smarten-ing up' one line of code, we have a 450%
> performance increase!
> 
> But this isn't the end of the story: we are still rendering
> at half the speed of blender 2.23! So I decided to
> investigate further ...
> 
> Doing some profiling in the scene yields that the code is now
> spending most of it's time in GetObjectByName() from the file
> source/blender/python/api2_2x/Object.c. This function gets called
> by setScriptLinks() from the file
> source/blender/python/api2_2x/EXPP_interface.c,
> which in turn is called by BPY_do_pyscript() from
> source/blender/python/BPY_interface.c -- but
> my scene with 4096 planes does not have any
> scriptlinks!
> 
> To confirm that this is a source of slowness, I made the first 
> executable line of code in BPY_do_pyscript() a 'return' statement
> -- the rendertime I get now is:
> 
> modified cvs: /tmp/render/0017 Time: 00:00.35
> 
> Now we are double the speed of blender 2.23!
> 
> Anyways, I hope this profiling information will inspire
> somebody on the python team to 'smarten up' the code
> that evaluates script links. (Maybe when ANIM/Alt-A is
> first pressed create a list of scripts that need to be run
> every frame, rather than figuring it out every frame?)
> 
> Chris
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers


=====
daniel dunbar
daniel@zuster.org