Hi, I created call.c when I worked on optimizations. I saw that performances depend on the code locality and that compilers are more eager to inline code when it's in the same file. Moreover, call.c now contains some private functions like function_code_fastcall() or _PyObject_CallFunctionVa() which are called from other public functions. Without call.c, some of these functions should be make "public" (exposed) which has also an impact on performance. Putting all these functions in the same file helps the compiler to produce more efficient code, but should also prevent inconsistencies when we modify a calling convention.
I'm not sure of the rationale behind the proposed call.h header. Is it difficult to maintain actual definitions in multiple header files? I'm used to them, it's easy to discover them, so *I* am not really convinced that call.h adds any value. I also expect fewer changes in header changes than in the implementation (call.c). Victor 2018-06-26 11:11 GMT+02:00 INADA Naoki <songofaca...@gmail.com>: > FYI, I don't against general refactoring, when I agree it's really make code > cleaner, readable. > > I against your PR because I didn't feel it really make code cleaner, > readable. > I already commented about it on the PR. > https://github.com/python/cpython/pull/7909#issuecomment-400219905 > > So it's not problem about general policy about refactoring / clean up. > It's just my preference. If Victor and Serhiy prefer the PR, I'm OK to > merge it. > > Regards, > > -- > INADA Naoki <songofaca...@gmail.com> > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com > _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
