[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: libsvn_repos logging -- design problems

From: <kfogel_at_collab.net>
Date: 2005-07-20 05:54:11 CEST

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? :-)


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.