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
unno
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
unnoticed this long.
*Except* when you're low on fr
[Bob Ippolito]
> ...
> What about for list objects that are big at some point, then
> progressively shrink, but happen to stick around for a while? An
> "event queue" that got clogged for some reason and then became stable?
It's less plausible that we''re going to see a lot of these
simultaneousl
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
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 re
[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-qualit
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 allocato
On Jan 3, 2005, at 3:23 PM, bacchusrx wrote:
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
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
On Jan 3, 2005, at 11:15 AM, Guido van Rossum wrote:
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 *
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 spe
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
[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 t
On Jan 3, 2005, at 12:13 AM, Tim Peters wrote:
[Bob Ippolito]
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.
I don't know what "relinquish some memory" means. If it means
something
[Bob Ippolito]
> 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.
I don't know what "relinquish some memory" means. If it means
something like "returns memory to the OS, so that t
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 implementati
16 matches
Mail list logo
