Josh Rosenberg <shadowranger+pyt...@gmail.com> added the comment:
How much bigger does the core interpreter + built-in extension modules get when you make this change? How much more memory is used by real world programs? I'm a little concerned when I see individual functions growing by 140 lines in the first file of the diff. Clearly the increase in memory usage wasn't enough to slow down the microbenchmarks (which can probably fit the entire hot code path in CPU on die cache), but I'd be worried about the aggregate effect on real world programs if we go from a handful of argument parsing code paths reused by every function (and therefore kept constantly hot) to hundreds (or thousands?) of unique argument parsing code paths, each one unique to a single function. It could easily look great when a single function is being called repeatedly, while looking much less great (possibly worse) when the many varied function calls are interleaved. It should be tested on a number of systems too; any losses to cache unfriendliness would be highly dependent on the size of the CPU cache. I'll grant, it doesn't seem like inlining positional argument parsing has caused problems, and it looks like we're still using _PyArg_UnpackKeywords, so argument parsing isn't completely devolved to each functions, but I think we need something more than microbenchmarks before we jump on this. If my worries end up being unfounded, I'll be happy. Looks very cool if we can really get that sort of speed up for all function calls, not just positional args only functions. :-) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36127> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
