list.pop(0) vs. collections.dequeue

[Stephen Hansen]

On Mon, Jan 25, 2010 at 9:31 AM, Steve Howell <showell30 at yahoo.com> wrote:

> Another way of looking at it is that you would need to have 250 or so
> lists in memory at the same time before the extra pointer was even
> costing you kilobytes of memory.  My consumer laptop has 3027908k of
> memory.
>

Umm, I think the issue here is that some people have use-cases which are
talking of number of lists whole orders of magnitude higher then you're
talking about here. In your program, maybe you only count the number of
lists in the hundreds, and so a few extra words wouldn't matter.

I have applications that have hundreds of thousands to millions of lists in
memory-- and which have to be managed somewhat carefully to avoid the 32-bit
memory allocation limit not smacking them (64-bit python isn't an option for
me presently).

I've never had an algorithm which needed to pop off the top of a list that I
couldn't with utter triviality simply operate in the reverse.

If Python's gonna get more memory hungry, I'd like to see how it benefits me
in some way. I mean, Unladen Swallow is talking about boosting Python's
memory need for the JIT, but I'm getting distinct performance improvements
out of that. That sounds like a fair trade.

You want Python to eat up a few more of my megs that I'd rather put to use
elsewhere, because... you don't want to just reverse your algorithm to treat
the FIFO as a LILO?

Sure, I can break my program up to run in separate processes and double how
much data I can have at once, with some IPC overhead. And if I got something
out of it, I'd be happy to! Or you can alter your algorithm. Why must I be
the one to change? :)

--S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20100125/613c3d74/attachment-0001.html>