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

[Daniel Dunbar]

> This just gets more and more interesting!.

Or less and less, as it just makes more apparent that
commits and code are in need of review. The chattering on 
IRC about debug prints getting left in commits gives the
same impression.

> > 
> > 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).
> 
> Question:  Under what circumstances would these
> not be equivalent?

When the object is not on the global object list, which
would be bad, or there is a different object of the same
name preceeding it on the global object list, which would
be bad if not worse.

In any case, neither is germane to the discussion, as the 
purpose of this bit of code is just to fetch the scriptlinks 
from the datablock.
 
> > 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.
> > 
> 
> Personally, I don't think the issue is naming conventions,
> but rather a lack of a high level view of blender internals.

That too. There are really two issues, 1) the GetObjectByName
call should be fast, because there should be a general routine
for doing that, backed by a scene hash table... its needed
in other places as well, but more importantly, 2) this code
just doesn't make sense.


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