Sorry meant to send this to the whole list:
John,
Thanks for the fix. After reading Eric's email I started to question
my profiling results but I still (without your fix) seem to see a
significant time when in Artist when generating large volumes of
graphs. I need t
> "Christopher" == Christopher Barker <[EMAIL PROTECTED]> writes:
Christopher> This sounds like a job for properties! make
Christopher> _transform a property, and code that gets and sets it
Christopher> directly should still work. though People that were
Christopher> accessing
John, Tom,
I don't understand how generation of the identity transform for each
Artist instance could possibly be a significant overall slowdown; it
should be very fast, and only a small part of the time required to
actually do anything useful with an Artist instance. I am wondering
whether t
John Hunter wrote:
> I'm hesitant to make a single (shared) identity transform since
> transforms are mutable.
Couldn't you make one that was immutable (is that possible in Python)?
Or even just have a convention that you don't mutate the identity
transform (though it could be way to late for th
> "Tom" == Tom Denniston <[EMAIL PROTECTED]> writes:
Tom> I've been profiling some of my code which builds many
Tom> somewhat complex graphs. I've noticed that it spends almost
Tom> all it's time in the __init__ of the artist class. The time
Tom> there is almost entirely spen
I've been profiling some of my code which builds many somewhat complex
graphs. I've noticed that it spends almost all it's time in the
__init__ of the artist class. The time there is almost entirely spent
on calling identity_transform which builds a SeperableTransform that
does no transforming--f
