(original) (raw)

On Mon, Jun 5, 2017 at 8:10 PM, Tim Peters <tim.peters@gmail.com> wrote:

\[Tim\]
\>> So at most 9 arenas ("highwater mark") were ever simultaneously allocated \[by the
\>> time the REPL prompt appeared in a 64-bit 3.6.1\]..

\> ... though not completely off-base.

Yes, 9 is in the ballpark of 16.

I think \_some\_ increase of arena size should be a no-brainer,

Maybe big enough to hold a bare, just started up interpreter?

but I
don't expect it to help a lot.

I was wondering about that -- in my experience with making re-sizable numpy arrays, (not the same use-case, I know!), I found that allocating memory wasn't all that slow, really. IN that use case, if you re-allocated every time you added a single element, it was dog-slow. But once you allocated less than, say, about every 10 or so, it started to make little difference how much you over-allocated.

In this case, I'm thinking that as long as there is a not-tiny arena, it just isn't going to make that much difference.

But only profiling will tell us.

-CHB

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov