New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
scary frame speed hacks #39815
Comments
In ceval.c we find
This patch takes that idea rather further than you Good for a ~5% improvement on "./python -s 'def f(): All three patches I just submitted together get ~6% on |
Logged In: YES I don't see any files attached. |
Logged In: YES sigh |
Logged In: YES (Side note first: I'm not sure 'builtins = back->f_builtins' Is the whole subclassing complexity worth the effort, given Moreover it requires a number of hacks here and there -- I cannot seem to get reliable performance results on my |
Logged In: YES I'm fairly sure this made a difference on my iBook; haven't It's possible that the correct response to this patch is to |
Logged In: YES Here is yet another try, which seems to perform better on my PentiumIII. I get the following speed improvements for this patch alone, for a loop calling an empty function: zombie-frames.diff: 11.4% (PyStone 3.8%) The idea is to get rid of the free_list and instead store the most recently finished ("zombie") frame in an internal field of the code object. This saves half of the frame creation overhead because half of the fields are already correct when the frame is reused, e.g. f_code, f_nlocals, f_stacksize, f_valuestack... (you might need to cvs up frameobject.c before you can apply the patch) |
Logged In: YES Did I mention this idea to you or did you come up with it I'll try to time stuff on my iBook tomorrow. |
Logged In: YES I guess the idea was just in the air, after your published attempts. Ideally I'd have liked to have the cached frame depend on the globals as well as the code object itself; I considered moving the cache field to function objects. This way you also save the f_globals and f_builtins initialization. There were problems but maybe we should try harder. |
Logged In: YES Armin's second patch gives gives the expected speedups on a |
Logged In: YES It slows recursive functions down a noticeable amount (did |
Logged In: YES The effect on recursive functions could be mitigated by I don't know if that is worth it. The current patch is a |
Logged In: YES On a small recursive example it slows down from 2.64s to 3.26s. |
Logged In: YES I think that's a question for python-dev. |
Logged In: YES Can this be reviewed for 2.5? The relevant discussion on |
Logged In: YES Patch modified and applied to python2.5. Mods:
See the "rjones-funccall" branch in SVN. |
Logged In: YES Closed as Accepted. While re-adding the free list removed |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: