On 11/28/2011 03:03 PM, Alan Meyer wrote:
On 11/24/2011 9:27 AM, Dave Angel wrote:
...
Several ways to speed up code.
1) use language features to best advantage
2) use 3rd party libraries that do certain things well
3) use best algorithms, subject to #1 and #2
4) have someone else review the code (perhaps on the list, perhaps
within your own organization)
5) measure (eg. profile it)
6) use optimizing tools, such as pypy or Cython.
7) rewrite parts of it in another language
8) get a faster processor
9) rewrite it all in another language
It takes experience to choose between these, and each project is
different. But even the most experienced developers will frequently
guess entirely wrong where the bottleneck is, which is why you measure
if you care.
I agree that measuring (profiling) is the most critical.
As you say, even the most experienced programmers can guess wrong.
The first time I used a profiler a couple of decades ago I was
egotistical enough to wonder how this thing could help me. After all,
I wrote the code. I knew what it did. The profiler wasn't going to
tell me anything I didn't know.
I learned a little humility after reading the profiler output. The
program was spending most of its time in a place that I never dreamed
was a problem, and a 10 minute fix cut run times in half.
In that particular case there wasn't even a design problem, it was
just a procedure call inside a tight loop that executed far more often
than I imagined and could be replaced with a few lines of inline code.
I think the rest of your list is excellent too.
Alan
Thanks. I once had an assignment to speed up a function implementation
which was obviously slow (I had noted the same thing to the architect
when I first saw the code; it would definitely be slow on large data
sets). I knew faster algorithms. But I stopped instead to measure how
many times it was being called in the particularly slow scenario that
the customer complained about. Turns out it wasn't being called at
all. I asked the appropriate developer why he had chosen to do it
another way (expecting he'd say because he knew this function was slow),
and he gave me an entirely different reason. I asked him whether he'd
be willing to call this function if I fixed his complaint about its
interface, and he agreed.
Now, I rewrote the function, making a change to tighten its interface
restrictions. And it cut the customer's wait time from 90 minutes to
2. Everyone was happy.
Total time spent, a week. But I didn't start coding till the 4th day.
--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
