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
[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 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
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
[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
