On 2/6/11 12:25 AM, Benjamin Peterson wrote: > 2011/2/5 Christian Tismer<tis...@stackless.com>: >> On 2/5/11 11:47 PM, Benjamin Peterson wrote: >>> 2011/2/5 Christian Tismer<tis...@stackless.com>: >>>> Howdy, >>>> >>>> studying the differences of PyPy vs. CPython, most seem to be fine; >>>> one thing where I an unsure is the __del__ behavior. >>>> >>>> I am not addressing its delayed call or the number it is called, this >>>> is similar to Jython and IronPython. >>>> >>>> But assigning to __del__ after a class is created, is that so hard >>>> to implement? >>> It's not a JIT problem rather a RPython/gc one. All the RPython >>> classes with finalizers must be known at translation time. __del__ is >>> expensive in the for gc. To implement user level __del__, a different >>> underlying interp class is used which has its own __del__ which the gc >>> will call. >> I understand. Then having a __del__ is always expensive, I guess? >> I mean, does it involve overhead to have a __del__ at all, runtime >> or compile time? > It just means there's a lot of runtime bookkeeping in the GC for > objects with __del__. > >> How feasible would it be to generate always two versions of >> the RPython class with a stub __del__ method, which calls a >> yet non-existing function? >> >> sorry if that is non-sense, but maybe something can be done >> to isolate these bad spots, without simply silently not calling them. > Well, you do at least get a nice warning. I don't think this is too > hard to work around in apps. There's also weakrefs. >
Ah, we do get a warning, that is good, did not know. Anyway, the concept of RPython is pretty old, since we needed something that is treatable. And RPython is a good compromise for most things. Meanwhile, a lot of evolution has happened, most of it in the JIT area, and maybe some things can be generated more lazily and taken over by the JIT, since dynamic changes like the sudden appearance of a method could probably be handled differently than it is right now. I will shut up, this is becoming a more general topic. ciao - chris -- Christian Tismer :^)<mailto:tis...@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
