[Python-Dev] Policy on refactoring/clean up

[Victor Stinner]

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 <songofacandy at 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  <songofacandy at gmail.com>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com
>