4 ms·

I haven't kept up with Python developments, but the fact that almost everything is a hash table (even stack frames for interpreted function calls, I believe) wo

I haven't kept up with Python developments, but the fact that almost everything is a hash table (even stack frames for interpreted function calls, I believe) would seem to place a relatively low upper-bound on performance. And this is in addition to the usual overhead of a straightforward interpreter.

stcredzero 17y ago
Stack frames in modern JIT VMs are just normal machine stack frames. When running in debugger mode, VisualWorks reifies the Object stack frames and runs the interpreter for that process as a program in the image. This way, you get speed for normal runtime, and access to everything as an object. This might seem like a bit of a stunt, but remember, the basic assumption for a JIT is that the JIT is a perfect simulation of bytecode interpretation. So if you have a valid JIT, you have a valid Debugger. This also means that anyone can extend the debugger, write tools based on it, or even write their own, as it's mostly an ordinary Smalltalk program. Then again, there's a few bad side effects from this. You have to copy the Debugger and its infrastructure to debug anything used by the Debugger. So, for example, you can't debug ListViews in the debugger, because the debugger application uses them! (But copying that stuff, and renaming is not a big deal in Smalltalk. Plus, it makes you feel like an uber-hacker.)
viraptor 17y ago
I'm not sure if that's a low upper-bound. He's complaining about an attribute access speed - but he's not trying to fix it... missed a great opportunity for __dict__ usage. From a quick py2.5 benchmark: noop 0.3s class_create 0.76s with_dict 1.68s without_dict 2.06s Functions tested 1,000,000 times - noop is an empty function for comparison; class_create is just x=A(); with_dict and without_dict create a class each time, assign 3 attributes, then read the same 3 attributes. with_... does it on an object that lists the attributes in __dict__, the other one doesn't use __dict__ and assigns attributes in the constructor. So... 1s (without the constructor and loop time) for 3,000,000 attribute reads and 3,000,000 attribute writes. Slow? Is he sure that it's the attribute read and write that's causing the problems? I'm not sure if I believe that without some more details - especially if he works with some documents that look like they're on some external storage (disk / db / whatever).

stcredzero 17y ago

Stack frames in modern JIT VMs are just normal machine stack frames. When running in debugger mode, VisualWorks reifies the Object stack frames and runs the interpreter for that process as a program in the image. This way, you get speed for normal runtime, and access to everything as an object. This might seem like a bit of a stunt, but remember, the basic assumption for a JIT is that the JIT is a perfect simulation of bytecode interpretation. So if you have a valid JIT, you have a valid Debugger. This also means that anyone can extend the debugger, write tools based on it, or even write their own, as it's mostly an ordinary Smalltalk program. Then again, there's a few bad side effects from this. You have to copy the Debugger and its infrastructure to debug anything used by the Debugger. So, for example, you can't debug ListViews in the debugger, because the debugger application uses them! (But copying that stuff, and renaming is not a big deal in Smalltalk. Plus, it makes you feel like an uber-hacker.)

viraptor 17y ago

I'm not sure if that's a low upper-bound. He's complaining about an attribute access speed - but he's not trying to fix it... missed a great opportunity for __dict__ usage. From a quick py2.5 benchmark: noop 0.3s class_create 0.76s with_dict 1.68s without_dict 2.06s Functions tested 1,000,000 times - noop is an empty function for comparison; class_create is just x=A(); with_dict and without_dict create a class each time, assign 3 attributes, then read the same 3 attributes. with_... does it on an object that lists the attributes in __dict__, the other one doesn't use __dict__ and assigns attributes in the constructor. So... 1s (without the constructor and loop time) for 3,000,000 attribute reads and 3,000,000 attribute writes. Slow? Is he sure that it's the attribute read and write that's causing the problems? I'm not sure if I believe that without some more details - especially if he works with some documents that look like they're on some external storage (disk / db / whatever).