pairs from a list

[George Sakkis]

On Jan 22, 1:34 pm, Paddy <paddy3... at googlemail.com> wrote:
> On Jan 22, 5:34 am, George Sakkis <george.sak... at gmail.com> wrote:
>
>
>
> > On Jan 22, 12:15 am, Paddy <paddy3... at googlemail.com> wrote:
>
> > > On Jan 22, 3:20 am, Alan Isaac <ais... at american.edu> wrote:> I want to generate sequential pairs from a list.
> > > <<snip>>
> > > > What is the fastest way? (Ignore the import time.)
>
> > > 1) How fast is the method you have?
> > > 2) How much faster does it need to be for your application?
> > > 3) Are their any other bottlenecks in your application?
> > > 4) Is this the routine whose smallest % speed-up would give the
> > > largest overall speed up of your application?
>
> > I believe the "what is the fastest way" question for such small well-
> > defined tasks is worth asking on its own, regardless of whether it
> > makes a difference in the application (or even if there is no
> > application to begin with).
>
> Hi George,
> You need to 'get it right' first.

For such trivial problems, getting it right alone isn't a particularly
high expectation.

> Micro optimizations for speed
> without thought of the wider context is a bad habit to form and a time
> waster.

The OP didn't mention anything about the context; for all we know,
this might be a homework problem or the body of a tight inner loop.
There is this tendency on c.l.py to assume that every optimization
question is about a tiny subproblem of a 100 KLOC application. Without
further context, we just don't know.

> If the routine is all that needs to be delivered and it does not
> perform at an acceptable speed then find out what is acceptable
> and optimise towards that goal. My questions were set to get
> posters to think more about the need for speed optimizations and
> where they should be applied, (if at all).

I don't agree with this logic in general. Just because one can solve a
problem by throwing a quick and dirty hack with quadratic complexity
that happens to do well enough on current typical input, it doesn't
mean he shouldn't spend ten or thirty minutes more to write a proper
linear time solution, all else being equal or at least comparable
(elegance, conciseness, readability, etc.). Of course it's a tradeoff;
spending a week to save a few milliseconds on average is usually a
waste for most applications, but being a lazy keyboard banger writing
the first thing that pops into mind is not that good either.

George