[Glyph Lefkowitz on __callattr__]
> CALL_ATTR should be implementable with no impact on existing python code,
> except bytecode hacks. It should be possible to retain a fully
> backwards-compatible __getattr__ method, for places where method objects are
> used (including the C API). Likewise, the default __callattr__ could be set up
> to first check if __getattr__ is defined, then the instance's dictionary or
> __slots__. For additional speed gains, new-object-model classes could set
> '__fast_methods__ = True' and gain a semantic distinction between __getattr__
> and __callattr__.
>
> Better still, I think that Jython could use the subtle semantic change
> to make Java reflection less expensive. (Java's `new' is more expensive than
> C's `malloc', after all.)
For the record, jython already have invoke(...) (what you call
__callattr__) and uses it to optimize certain simple method calls on
instances. It is not currently used to optimize calls into java reflection.
Oh, as a cute aside, when I tried to run your timing program, I realized
that the optimization had been disabled by mistake in CVS during the AST
parse tree rewrite. Thanks for your help in pointing that out.
Without the "invoke" optimization, I get these numbers:
2.865000009536743
1.7020000219345093
With the optimization added, I get this:
2.052999973297119
1.652999997138977
regards,
finn
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4