On Jan 4, 2005, at 5:56 AM, Jack Jansen wrote:
On 3 Jan 2005, at 23:40, Bob Ippolito wrote:
Most people on Mac OS X have a lot of memory, and Mac OS X generally
does a good job about swapping in and out without causing much of a
problem, so I'm personally not very surprised that it could go
On Jan 3, 2005, at 2:16 AM, Tim Peters wrote:
[Bob Ippolito]
...
Your expectation is not correct for Darwin's memory allocation scheme.
It seems that Darwin creates allocations of immutable size. The only
way ANY part of an allocation will ever be used by ANYTHING else is if
free() is called with
Coming late to this thread.
I don't see the point of lying awake at night worrying about potential
memory losses unless you've heard someone complain about it. As Tim
has been trying to explain, here are plenty of other things in Python
that we *could* speed up if there was a need; since every
On Thu, Jan 01, 1970 at 12:00:00AM +, Tim Peters wrote:
Is there any known case where Python performs poorly on this OS, for
this reason, other than the pass giant numbers to recv() and then
shrink the string because we didn't get anywhere near that many bytes
case?
[...]
I agree the
On Jan 2, 2005, at 11:16 PM, Tim Peters wrote:
[Bob Ippolito]
However, it is our (in the I know you use Windows but I am not the
only
one that uses Mac OS X sense) problem so long as Darwin is a supported
platform, because it is highly unlikely that Apple will backport any
fix to
the allocator
[Tim Peters]
Ya, I understood that. My conclusion was that Darwin's realloc()
implementation isn't production-quality. So it goes.
[Bob Ippolito]
Whatever that means.
Well, it means what it said. The C standard says nothing about
performance metrics of any kind, and a production-quality
On Mon, Jan 03, 2005 at 03:55:19PM -0500, Bob Ippolito wrote:
Note that, with respect to http://python.org/sf/1092502, the author
of the (original) program was using the documented interface to a
file object. It's _fileobject.read() that decides to ask for huge
numbers of bytes from recv()
On Jan 3, 2005, at 4:49 PM, Tim Peters wrote:
[Tim Peters]
Ya, I understood that. My conclusion was that Darwin's realloc()
implementation isn't production-quality. So it goes.
[Bob Ippolito]
Whatever that means.
Well, it means what it said. The C standard says nothing about
performance metrics
Quite a few notable places in the Python sources expect realloc(...) to
relinquish some memory if the requested size is smaller than the
currently allocated size. This is definitely not true on Darwin, and
possibly other platforms. I have tested this on OpenBSD and Linux, and
the
[Bob Ippolito]
...
Your expectation is not correct for Darwin's memory allocation scheme.
It seems that Darwin creates allocations of immutable size. The only
way ANY part of an allocation will ever be used by ANYTHING else is if
free() is called with that allocation.
Ya, I understood that.
10 matches
Mail list logo
