bpo-44501: pack call arguments on the compiler

[isidentical]

https://bugs.python.org/issue44501

[pablogsal]

Hummm, unfortunately I think this is a lot of code for no general performance increase. Although it may make sense as a targeted optimization I don't see a clear win in terms of complexity and performance increase in the topical cases. I would like maybe other core Devs to mention what be they think, maybe we are collectively ok with it so we should merge it.

[isidentical]

Hummm, unfortunately I think this is a lot of code for no general performance increase

I would argue that this is a lot of code, since it is just a single function in the AST optimizer (fold_call). No change on the compiler/interpreter, and the logic for the new function is pretty straight-forward (wrapping the arguments into a tuple). Also even though the pyperformance suite is unaffected by this (which was expected), there seem to be a lot of occurrences (nearly 100k cases, where this optimization can create a speed-up between %5 - %35 (maybe more?)), including some use cases within the standard library.

I would like maybe other core Devs to mention what be they think, maybe we are collectively ok with it so we should merge it.

We could wait for a bit on the tracker.

[pablogsal]

here seem to be a lot of occurrences (nearly 100k cases, where this optimization can create a speed-up between %5 - %35 (maybe more?)), including some use cases within the standard library.

Right, but without a realistic benchmark to see the actual benefit of this is complicated to make an informed decision. For scoped optimizations we normally target higher numbers.

In any case, this is only my opinion on the matter but I also have an open mind about it 😉

[pablogsal]

Actually, I retire my objection, as the core of the change is very scoped. I still think this is a small improvements but I think the changes may be worth the cost as they are very scoped and not very complex.

I'm +0.5 :)

[isidentical]

@serhiy-storchaka what do you think? (I've posted the detailed answers to your question in the tracker)

[isidentical]

@serhiy-storchaka if you have no objections (at least that is what I was able to infer from your last comment at the tracker), I intend to merge this.

[serhiy-storchaka]

I afraid that we are in situation of having hammer and looking for nails. Too little code will get benefit from this optimization. It would be perhaps good if it only require adding 3 lines of code, but it adds 50.

[isidentical]

Thanks for the reviews then! I still believe the absolute amount of code added (50~ lines) doesn't actually complicate the code, since it is in an isolated function in the AST optimizer, and shows significant improvements (up to %30 speed-up on some function calls, including re.match().group(...)) but I see your concerns.