On Apr 29, 6:50 pm, Joe Wreschnig <[email protected]> wrote: > I am also trying to maintain compatibility with existing pyglet code.
I've tested the runtime differences between backwards compatible and typeswitching variants: http://paste.pocoo.org/show/207971/ I basically observe that: 1) tuple unpacking directly is about 20% slower then single value assignment 1) tuple unpacking is a bit faster then tuple indexing (about 20%) 2) typeswitching on Real is very slow 3) typeswitching either on a tuple of type values or in an if/elif construct incurs an overhead between 50% - 150% (depending on what type is preferred) I think that this is a typical example of a backwards compatibility vs. convenience vs. performance tradeoff decision, these are the choices: 1) You can remain backwards compatible and support the new semantics, but be between 2x - 5x slower in attribute assignment 2) You can forgo backwards compatibility and be 1.2x slower in attribute assignment (albeit for 2 values, which is apples vs. oranges) 3) You can keep backwards compatibility and not support new semantics, but be 2x slower (because you force a user to make 2 function calls for both attributes) How relevant such micro optimization is, of course, is another question entirely, but it makes a nice bikeshed (I tend to think that when thinking this way about a problem, something is fundamentally wrong in the usage). -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
