[emirplus]

Fixes #160050.

In Objects/longobject.c, l_divmod switches to pylong_int_divmod() when operands exceed the threshold (size_w > 300 && (size_v - size_w) > 150), providing asymptotically faster division. However, l_mod() bypassed this fast path and fell through directly to long_rem(), resulting in integer modulo (%) taking significantly longer than divmod(a, b)[1] for large integers.

This patch adds the same WITH_PYLONG_MODULE threshold check in l_mod(), invoking pylong_int_divmod(v, w, NULL, pmod) when sizes exceed the threshold.

Benchmark

Using the benchmark from the issue with operands where bits = 128_000:

• Before: // = 0.0105s, % = 0.0224s, divmod = 0.0083s (modulo ~2.1x slower than integer division)
• After: // = 0.0088s, % = 0.0093s, divmod = 0.0098s (modulo has matching complexity)

Testing

• Added test_pylong_int_mod in Lib/test/test_int.py.
• Extended test_pylong_int_divmod_crash to cover %.
• Verified all tests pass with ./PCbuild/amd64/python.exe -m test test_int test_long.

• Issue: modulo for huge integers has the wrong complexity #160050

[skirpichev]

CC @picnixz

[StanFromIreland]

Suggested change

	n = (1 << 100_000)
	self.assertEqual((n * 3 + 1) % n, 1)
	self.assertEqual((-n * 3 - 1) % n, n - 1)
	self.assertEqual((n * 3 + 1) % -n, 1 - n)
	self.assertEqual((-n * 3 - 1) % -n, -1)
	n = (1 << 100_000)
	m = (1 << 50_000)
	self.assertEqual((n * 3 + 1) % m, 1)
	self.assertEqual((-n * 3 - 1) % m, m - 1)
	self.assertEqual((n * 3 + 1) % -m, 1 - m)
	self.assertEqual((-n * 3 - 1) % -m, -1)

We don't reach the path currently, at n = 1 << 100_000, both n*3 + 1 and n are 3334 digits, so size_v - size_w is 0 and the threshold of 150 is never met?

[emirplus]

Good catch! Applied the suggestion to ensure size_v - size_w > 150 and size_w > 300 thresholds are properly exercised. Thanks!