Marc-Andre Lemburg <m...@egenix.com> added the comment:
On 15.11.2021 10:54, STINNER Victor wrote: > > I don't understand what you are trying to prove about compilers not inlining > when you explicitly ask them... not to inline. I'm not trying to prove anything, Victor. I'm only stating the fact that by switching from macros to inline functions we are giving away control to the compilers and should not be surprised that Python now suddenly runs a lot slower on systems which either have inlining optimizations switched off or where the compiler (wrongly) assumes that creating more assembler would result in slower code. I've heard all your arguments against macros, but don't believe the blanket approach to convert to inline functions is warranted in all cases, in particular not for code which is private to the interpreter and where we know that we need the code inlined to not result in unexpected performance regressions. I also don't believe that we should assume that Python C extension authors will unintentionally misuse Python API macros. If they do, it's their business to sort out any issues, not ours. If we document that macros may not be used as l-values, that's clear enough. We don't need to use compiler restrictions to impose such limitations. IMO, conversion to inline functions should only happen, when a) the core language implementation has a direct benefit, and b) it is very unlikely that compilers will not inline the code with -O2 settings, e.g. perhaps using a threshold of LOCs or by testing with the website Oleg mentioned. Overall, I think the PEP 670 should get some more attentions from the SC to have a guideline to use as basis for deciding whether or not to use the static inline function approach. That way we could avoid these discussions :-) BTW: Thanks for the details about -O0 vs. -Og. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue45476> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
