Avoid temporary allocation in dec_as_long()

[skirpichev]

Feature or enhancement

Proposal:

After #127925, new code in the decimal module (using the PEP 757) do temporary allocation with mpdecimal's memory functions (in mpd_qexport_u32/16()), just as before:

cpython/Modules/_decimal/_decimal.c

Lines 3691 to 3706 in f10b7b2

	uint32_t base = (uint32_t)1 << layout->bits_per_digit;
	/* We use a temporary buffer for digits for now, as for nonzero rdata
	mpd_qexport_u32/u16() require either space "allocated by one of
	libmpdec’s allocation functions" or "rlen MUST be correct" (to avoid
	reallocation). This can be further optimized by using rlen from
	mpd_sizeinbase(). See gh-127925. */
	void *tmp_digits = NULL;
	size_t n;
	status = 0;
	if (layout->digit_size == 4) {
	n = mpd_qexport_u32((uint32_t **)&tmp_digits, 0, base, x, &status);
	}
	else {
	n = mpd_qexport_u16((uint16_t **)&tmp_digits, 0, base, x, &status);
	}

According to the documentation, we can prepare array of digits, which size could be estimated by mpd_sizeinbase(). Given this, the mpd_qexport_u32/16() shouldn't do any resize for this array. Here is Stefan comment on how safe this approach is:

mpd_sizeinbase() uses log10() from math.h for performance reasons. If log10() is IEEE compliant, the result should be sufficiently large. Resizing is for guarding against broken log10() implementations.

The current code in _decimal.c sets the libmpdec allocation functions to PyMem_Malloc() etc. So if longobject uses PyMem_Free() it is safe even when resizing occurs.

If the new API allows for allocators other that PyMem_Malloc(), it will rely on the IEEE compliance of log10().

Stefan Krah

We can expect slight performance boost for small (2-3 digits) integers.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Linked PRs

• gh-129275: avoid temporary buffer in dec_as_long() #129630