<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 8, 2013 at 5:18 AM, Daniel Holth <span dir="ltr"><<a href="mailto:dholth@gmail.com" target="_blank">dholth@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Mar 8, 2013 at 5:07 AM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>


> Le Fri, 08 Mar 2013 08:16:59 +0900,<br>
> "Stephen J. Turnbull" <<a href="mailto:stephen@xemacs.org">stephen@xemacs.org</a>><br>
> a écrit :<br>
>><br>
>>  > > But why do you think allocation is slow in the general case?<br>
>>  > > Sure, it involves system calls which indeed do slow things down.<br>
>>  ><br>
>>  > It depends what one calls a system call. A memory allocation<br>
>>  > shouldn't always incur a call to the kernel. Library calls can be<br>
>>  > quite fast.<br>
>><br>
>> If the process itself is growing, eventually it does.<br>
><br>
> I think most allocators would request big chunks of memory from the<br>
> kernel, and then carve out the small blocks requested by the user from<br>
> that. Therefore, my intuition is that a long-running process, if not<br>
> leaky, should end up not stressing mmap / sbrk system calls too much.<br>
><br>
>> And I suspect that Alex (and Christian!) would consider saving a few<br>
>> CPU cycles in an inner loop very important.<br>
><br>
> They probably would, but that is not a design point for Python.<br>
><br>
> Regards<br>
><br>
> Antoine.<br>
<br>
</div>I am a fan of the proposal. Imagine you are programming for a<br>
memory-constrained system. By telling the list how big it needs to be<br>
you can save precious RAM. It's a pretty standard feature to be able<br>
to hint and trim the size of data structures, just like you can<br>
usually choose the buffer size for stream operations.<br>
<div class="HOEnZb"><div class="h5">__________________________________<br></div></div></blockquote></div><br></div><div class="gmail_extra">If it's voting time, I'm -1. Having programmed a lot of memory-constrained systems (not in Python, though) - this is not how things usually work there. In a memory-constrained system, you don't "grow and shrink" your data structures. That's because growing often needs to reallocate the whole chunk and do a copy, and shrinking only helps memory fragmentation. In such systems, you usually know in advance or at least limit the size of data structures and pre-allocate, which is perfectly possible in Python today. Shrinking is rarely, if ever, useful. If it is, you can implement concrete data structures for your concrete needs. And Python has a lot of ways to save memory for large arrays of things (array, numpy, encoding in bytes, etc) if one really wants to. I just don't believe the proposal will help in a lot of realistic code, and it certainly goes against the way of Python.<br>

<br>Eli<br></div><div class="gmail_extra"><br><br></div></div>