[Tim]
>> At the start, obmalloc never returned arenas to the system. The vast
>> majority of users were fine with that.
[Neil]
> Yeah, I was totally fine with that back in the day. However, I
> wonder now if there is a stronger reason to try to free memory back
> to the OS. Years ago, people wo
On 2019-06-15, Tim Peters wrote:
> At the start, obmalloc never returned arenas to the system. The vast
> majority of users were fine with that.
Yeah, I was totally fine with that back in the day. However, I
wonder now if there is a stronger reason to try to free memory back
to the OS. Years ag
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 unless we
can show it doesn't hurt these micro-benchmarks. To displace t
[Tim. to Neil]
>> Moving to bigger pools and bigger arenas are pretty much no-brainers
>> for us, [...]
[Antoine]
> Why "no-brainers"?
We're running tests, benchmarks, the Python programs we always run,
Python programs that are important to us, staring at obmalloc stats
... and seeing nothing bad
On Sat, 15 Jun 2019 01:15:11 -0500
Tim Peters wrote:
>
> > ...
> > My feeling right now is that Tim's obmalloc-big-pool is the best
> > design at this point. Using 8 KB or 16 KB pools seems to be better
> > than 4 KB. The extra complexity added by Tim's change is not so
> > nice. obmalloc is a
