low level optimization

[Stanley Friesen]

In article <790 at cadlab.sublink.ORG> martelli at cadlab.sublink.ORG (Alex Martelli) writes:
>rkowen at violet.berkeley.edu (Dario Bressanini) writes:
 	...
>:When i REALLY HAVE to optimize a program, first of all i use 
>:a profiler to see where is the bottleneck, and THEN i try to optimize it;
>: ...
>Ciao Dario!  In interactive tasks such as solid modeling and CAD, you
>would still find (in my experience) 'single-bottlenecks' responsible for
>heavy slowdown of many tasks (no, not 95%!, but 30-40% are not uncommon),
>except that different tasks, and different users, would hit different
>bottlenecks - as a commercial program evolves over many releases, the
>various 'specific bottlenecks' are found and removed.

Quite, I too optimize after profiling.  And most of the time there seems to
be one specific bottleneck.

One of the most interesting I have ever found was one involving union
assignment.   The program had a union somewhat like this:

union any_type {
	int    i;
	long   l;
	double d;
	char   *str;
	struct stuff s;
};

At several places in the code the original writr had used union/struct
assignment to copy the value of this union.  The compiler dutifully
inserted a tight copy loop to copy the entire union for each assignment.
As a result the program spent nearly 1/3 of its time copying the union!!

I simply replaced each assignment with a switch on the actual type and
assigned only the active member of the union - voila a *huge* improvement.


So, be watch out for this one!  (It took me several days to figure out why
simple linear code with no (explicite) loops was using up all of the time!!
I had to disassemble the binary and locate the in-line copy loop)
-- 
---------------
uunet!tdatirv!sarima				(Stanley Friesen)