deque vs list: performance notes

Courageous jkraska1 at san.rr.com
Wed May 31 21:30:35 EDT 2000


> > When benching your code, I was surprised for a moment that
> > your 1000 entry test was so much faster than mine (I ran
> > the test a half dozen times), but then discovered that my
> > original reported result in that category was a typo. Whoops.
> > This does make a very compelling case for the deque in
> > deque implementations likely to hold 1,000 or so objects
> > (rare, probably).
> 
> There's also one other point which should probably be included in any
> such discussion, although I expect those following this thread are
> implicitly aware of it.  Whether or not the above numbers make a "very
> compelling" case can't be gauged from the numbers alone, but must take
> into account the overall operation of the surrounding application -
> even for native lists.

Err, right. Generally I begin my optimization with algorithms
at the top of the profiler readout. For example, in my simulation
environment, the single biggest consumer of time is the priority
queue. Hence the attempt to optimize it.

The implementation of the deque was more of an academic exercise.
Several people here posted that it wasn't particularly relevant
to most everyday problems. I didn't believe them.

:)

C/



More information about the Python-list mailing list