[Tutor] list comprehension, testing for multiple conditions
Pete O'Connell
pedrooconnell at gmail.com
Thu Aug 23 01:23:59 CEST 2012
Ok thanks for the advice everyone.
Cheers
Pete
On Thu, Aug 23, 2012 at 10:58 AM, Jerry Hill <malaclypse2 at gmail.com> wrote:
> On Wed, Aug 22, 2012 at 5:23 PM, Pete O'Connell <pedrooconnell at gmail.com> wrote:
>> OK maybe I am wrong about it being slow (I thought for loops were
>> slower than lis comprehensions). But I do know I need it to be as fast
>> as possible if I need to run it on a thousand files each with hundreds
>> of thousands of lines
>
> You're quite likely wrong about that. The overall runtime of your
> code is very likely to end up dominated by I/O with the hard drive,
> not the microsecond differences in how you process each line. The way
> to know for sure is to write code that is easy to read and does the
> correct thing. Then run the code an see if it's too slow for your
> purposes. If it is, profile the code and see where it's spending all
> of its time. Only then can you actually optimize the right places.
>
> Once you've identified where your code needs to be faster, you're
> likely to get more mileage out of a clever algorithm change than a
> micro-optimization to your filtering. Or maybe you'll discover that it
> really is worthwhile to optimize your filtering, because it's inside a
> tight loop, and that's where all of your time is spent. There are a
> lot of tricks you can use to slightly speed up your python code, but
> none of them are worth doing until you know for sure that you're
> optimizing in the right place. And if it turns out that the code's
> runtime is fine as first written, you don't have to waste your time
> doing lots of work for little gain.
>
> --
> Jerry
> _______________________________________________
> Tutor maillist - Tutor at python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/mailman/listinfo/tutor
--
-
More information about the Tutor
mailing list