Greg Hudson <ghudson@MIT.EDU> writes:
> For the kind of logging we will actually be adding (and so far, no one
> has had a *single* counterexample to this), the purported benefits allow
> us to save a few cycles before executing an operation such as "checkout"
> which will take millions upon millions of cycles to execute.
>
> Compared to that, the readability of a varargs function is orders of
> magnitude more important.
I'd like to suggest that we resolve this debate in favor of the
function, not the macro. Here's why:
The penalties of using a macro are definite. Greg has listed them
ably, no one need wonder what they are. If we use a macro, we know
for sure we will suffer these penalties -- however minor they may be,
we *will* experience them.
The penalties of using a function are not definite. They are
tentative predictions, based on Brane's (and perhaps others')
experiences with other programs. Real-world experience is valuable,
but there are two different ways to take advantage of it:
1) We can decide we're likely to have the same problems, and
preëmptively go with the macro, or
2) We can remember that these problems are a possibility, and keep
a watchful eye for them when profiling and when receiving
reports of performance problems. If the function calls ever
become a problem in real life, we switch to the macro system.
This would be a trivial coding effort, nor would the old code be
wasted, since most of the work of writing logging calls is
choosing where to put them and what information to log.
Brane's telling us something we need to know, but that doesn't mean we
must assume the worst will happen. It's enough that he helps us be
aware that the worst *can* happen.
So: can we please start with the function-based system, and stay away
from pink.bikeshed.com? :-)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 20 23:06:33 2005