On Sat, 15 Jun 2019 19:56:58 -0500
Tim Peters wrote:
>
> At the start, obmalloc never returned arenas to the system. The vast
> majority of users were fine with that. A relative few weren't. Evan
> Jones wrote all the (considerable!) code to change that, and I
> massaged it and checked it in -
On Sat, 15 Jun 2019 22:02:35 -0600
Neil Schemenauer wrote:
> On 2019-06-15, Antoine Pitrou wrote:
> > We should evaluate what problem we are trying to solve here, instead
> > of staring at micro-benchmark numbers on an idle system.
>
> I think a change to obmalloc is not going to get accepted u
[Antoine]
> We moved from malloc() to mmap() for allocating arenas because of user
> requests to release memory more deterministically:
>
> https://bugs.python.org/issue11849
Which was a good change! As was using VirtualAlloc() on Windows.
None of that is being disputed. The change under discuss
obmalloc is very nice at allocating small (~224 bytes) memory blocks.
But it seems current SMALL_REQUEST_THRESHOLD (512) is too large to me.
```
>>> pool_size = 4096 - 48 # 48 is pool header size
>>> for bs in range(16, 513, 16):
... n,r = pool_size//bs, pool_size%bs + 48
... print(bs, n,
[Inada Naoki ]
> obmalloc is very nice at allocating small (~224 bytes) memory blocks.
> But it seems current SMALL_REQUEST_THRESHOLD (512) is too large to me.
For the "unavoidable memory waste" reasons you spell out here,
Vladimir deliberately set the threshold to 256 at the start. As
things tur
