This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: dtoa.c: remove custom memory allocator
Type: Stage:
Components: Versions: Python 3.5
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: eric.smith, mark.dickinson, pitrou, serhiy.storchaka, skrah, vstinner
Priority: normal Keywords: patch

Created on 2014-08-17 19:55 by vstinner, last changed 2022-04-11 14:58 by admin. This issue is now closed.

File name Uploaded Description Edit
dtoa_remove_custom_alloc.patch vstinner, 2014-08-17 19:55 review
Messages (5)
msg225465 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014-08-17 19:55
dtoa.c has an optimized memory allocator for performances: it uses a short pool of 2304 doubles (18 KB) to avoid calling malloc/free. Comment in dtoa.c:

/* Memory management: memory is allocated from, and returned to, Kmax+1 pools
   of memory, where pool k (0 <= k <= Kmax) is for Bigints b with b->maxwds ==
   1 << k.  These pools are maintained as linked lists, with freelist[k]
   pointing to the head of the list for pool k.

   On allocation, if there's no free slot in the appropriate pool, MALLOC is
   called to get more memory.  This memory is not returned to the system until
   Python quits.  There's also a private memory pool that's allocated from
   in preference to using MALLOC.

   For Bigints with more than (1 << Kmax) digits (which implies at least 1233
   decimal digits), memory is directly allocated using MALLOC, and freed using

   XXX: it would be easy to bypass this memory-management system and
   translate each call to Balloc into a call to PyMem_Malloc, and each
   Bfree to PyMem_Free.  Investigate whether this has any significant
   performance on impact. */

Python already has such memory pool: PyObject_Malloc(). I propose to reuse it. It avoids wasting memory "until Python quits" just to optimize dtoa.c.

dtoa.c memory pool is only used for allocations smaller than 68 bytes (on 64 bits system, Kmax=7). PyObject_Malloc() is optimized for allocations smaller than 513 bytes, so it's ok.

See also the issue #7632.
msg225470 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-08-17 20:38
This is very dangerous change. Could you please compare results of Python benchmarks with and without the patch?
msg225473 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2014-08-17 21:20
A modified version of (using floats instead of decimals) runs
about 5-6% slower with the change here.
msg225963 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014-08-27 10:38
> A modified version of (using floats instead of decimals)
> runs about 5-6% slower with the change here.

Would it be possible to optimize the pymalloc allocator to reduce this slow-down?
msg228580 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014-10-05 15:28
I was no aware of the performance degradation when I created the issue. 18 KB of memory is too low to invest effort on optimizing the generic Python memory allocator, I prefer to keep the heavily optimized allocator in dtoa.c.
Date User Action Args
2022-04-11 14:58:07adminsetgithub: 66418
2014-10-05 15:28:29vstinnersetstatus: open -> closed
resolution: not a bug
messages: + msg228580
2014-08-27 10:38:00vstinnersetmessages: + msg225963
2014-08-17 22:25:08eric.smithsetnosy: + eric.smith
2014-08-17 21:20:58skrahsetmessages: + msg225473
2014-08-17 20:38:47serhiy.storchakasetnosy: + serhiy.storchaka, pitrou
messages: + msg225470
2014-08-17 19:55:29vstinnercreate