[issue42304] [easy C] long type performance waste in 64-bit Windows build

Ma Lin added the comment: > I do not think that this is suitable for newcomers because you need to have > deep understanding why it was written in such form at first place and what > will be changed if you change it. I agree contributors need to understand code, rather than simply replace

[issue42304] [easy C] long type performance waste in 64-bit Windows build

STINNER Victor added the comment: > There are several different problems, such as: > https://github.com/python/cpython/blob/v3.10.0a2/Modules/mathmodule.c#L2033 I don't think that it's worth it to optimize this one. > In addition, `utf16_decode` also has this problem, I forgot this:

[issue42304] [easy C] long type performance waste in 64-bit Windows build

Serhiy Storchaka added the comment: I do not think that this is suitable for newcomers because you need to have deep understanding why it was written in such form at first place and what will be changed if you change it. The code was written when unsigned long long was not standard and

[issue42304] [easy C] long type performance waste in 64-bit Windows build

Ma Lin added the comment: > What is the problem exactly? There are several different problems, such as: https://github.com/python/cpython/blob/v3.10.0a2/Modules/mathmodule.c#L2033 In addition, `utf16_decode` also has this problem, I forgot this:

[issue42304] [easy C] long type performance waste in 64-bit Windows build

Serhiy Storchaka added the comment: What is the problem exactly? -- nosy: +serhiy.storchaka ___ Python tracker ___ ___

[issue42304] [easy C] long type performance waste in 64-bit Windows build

New submission from Ma Lin : C type `long` is 4-byte integer in 64-bit Windows build (MSVC behavior). [1] In other compilers, `long` is 8-byte integer in 64-bit build. This leads to a bit unnecessary performance waste, issue38252 fixed this problem in a situation. Search `SIZEOF_LONG` in