Re: Returning values from a function
From: Martijn Lievaart (m_at_rtij.nl.removefromhere.invalid)
Date: 10/23/03
- Next message: Dan Pop: "Re: clock() function"
- Previous message: Christopher Benson-Manica: "Re: enum"
- In reply to: E. Robert Tisdale: "Re: Returning values from a function"
- Next in thread: Martijn Lievaart: "Re: Returning values from a function"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 23 Oct 2003 14:30:56 +0200
On Tue, 21 Oct 2003 11:14:12 -0700, E. Robert Tisdale wrote:
> Premature optimization is a sin.
Absolutely.
> Write code that is easy to read, understand and maintain.
Absolutely.
> Exhaust your compiler's optimization options first.
> Shop around for a better optimizing compiler second.
> Only then should you run your profiler
> and consider cobbling your code to make it run faster.
I don't completely agree here.
First, investigate it. Is it really the program that's causing the delay?
F.I. network protocols without some form of pipelining often are a
bottleneck. I've seen cases where the networkcard was experiencing
congestion becuase of a low mtu. Or is disk I/O the bottleneck? Sometimes
you cannot tell without a profiler, but I found that fairly simple
measurements can give a lot of insight.
I've seen to often that optimization options introduce compiler bugs to
play with them lightly. Also, deviating from the default optimization most
often gives only marginal gains, though for some programs the savings can
be enormous.
An other compiler is often not an option. F.I. opensource often only
compiles on gcc. OTOH, it's an option that is often overlooked. Intel
makes some fairly good compilers that should be drop in replacements for
others (most notably MSVC). A big win if you do numbercrunching.
And before switching compilers, you should profile. More often than not,
some fairly simple changes can make a huge difference. More intelligent
algrithms are the number one efficiency gain, often speeding up a program
by several orders. Switching to non-blocking I/O is another good one
sometimes. I once found through profiling that a program was busy about
20% of the time in converting UTF-8 to and from UCS32. Some simple caching
on this (a 5 minutes patch, isn't encapsulation wonderful) saved that 20%
almost completely.
Just doing a code review can be helpful, sometimes you find that you copy
objects needlessly. Sometimes it helps to break encapsulation to avoid
copies. But first profile to see if this is where the bottlenecks are.
But the number one advice still is measure, measure, measure. Start with
some real world tests and time them. Zoom in on the bottlenecks, some
print statements in the code can be a cheap and effective profiler. Don't
assume, measure. Programmers are notoriously bad at optimizing by
experience, so you need hard facts.
M4
- Next message: Dan Pop: "Re: clock() function"
- Previous message: Christopher Benson-Manica: "Re: enum"
- In reply to: E. Robert Tisdale: "Re: Returning values from a function"
- Next in thread: Martijn Lievaart: "Re: Returning values from a function"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
