Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!van-bc!root
From: lphillips@lpami.wimsey.bc.ca (Larry Phillips)
Newsgroups: comp.sys.amiga
Subject: Re: To macro, or not to macro?  (LONG) ... a programming style.
Message-ID: <2457@van-bc.UUCP>
Date: 6 Jun 89 14:21:57 GMT
Sender: usenet@van-bc.UUCP
Lines: 54

In <375@xdos.UUCP>, doug@xdos.UUCP (Doug Merritt) writes:
>In article <2454@van-bc.UUCP> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
>>The inefficiency comes when my macro is defined as: [...]
>>       move.l  \1,a0		[...]
>>which will, of course generate:
>>       move.l  a0,a0
>>       bsr     printit

>Although your point is in general quite reasonable, in this example
>it is inappropriate because the extra overhead of the move will be
>totally swamped by the overhead of the call to printit. There is
>no conceivable situation in which the difference would be measurable.

 In my defense, I will point out that I said it was worth it, and that I would
call the subroutine only if I was being picky. :-)

>Actually this just confirms your point that macro efficiency is often
>not a problem. And in fact many macros in both assem and C will be
>*faster* than doing a subroutine call, and this can be a *very* important
>programming tool. It's often possible to get a 20% overall improvement
>by converting a C call to a macro, and I've gotten far more than that
>at times.

>But it's important to be careful, when optimizing, not to spend any
>time optimizing something that will never have a measurable effect.
>This is often one of the earmarks of an expert programmer versus a
>hacker-wanna-be (present company excluded, of course).
>	Doug

Yes, it's all to easy to be 'cycle wise and algorithm foolish'. There isn't much
point in scraping off a few cycles here and there in inline code (init,
cleanup, etc.), or in an inefficient algorithm (if there's a better one
available).

I have just finished the first cut of a 'find' program that runs like greased
lightning, and is less than 2500 bytes long. It searches a file that is built
by a companion 'updatedb' program, and uses a Boyer-Moore search algorithm. The
point being that the Boyer-Moore search is a massive improvement over the 'brute
force' search, and I probably gained more using it than I would have gained in
a week of hand optimization. How much more fun it is to tweak a piece of code
that takes 3 seconds than to tweak one that takes 10 seconds. :-)

I now find myself in a position of having both small size and good speed, so I
have room to juggle the two.

-larry

--
Van Roy's Law:  An unbreakable toy is useful for breaking other toys.
+----------------------------------------------------------------------+ 
|   //   Larry Phillips                                                |
| \X/    lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips  |
|        COMPUSERVE: 76703,4322                                        |
+----------------------------------------------------------------------+