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

Re: [PATCH]: A newer, better, svndiff

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2002-02-15 17:21:57 CET

On Thu, 2002-02-14 at 23:11, Daniel Berlin wrote:
> It varies, but it can be upwards of 50%, actually.
> Averages to 15%.

Okay, I think a 15% savings is definitely worth a little additional

> Errr, I didn't want it reviewed on nitpicky issues or commenting issues
> because i'm not finished with that stuff yet.

My apologies, then, I must have misinterpreted.

> > One general note is that your code uses tabs. I think most Subversion
> > code doesn't (svn-dev.el sets indent-tab-mode to nil) so that diffs look
> > pretty and stuff.
> I load svn-dev.el before working on .c files, so i'm a bit confused on
> this one.

Maybe emacs version skew issues? C-mode often changes enough between
versions to break people's customizations.

> > Unless you have a compelling reason to do otherwise, use arrays for the
> > near and same tables. They're small and always the same size; it will
> > save significantly on code complexity.
> What code complexity? It just saves you about 4 lines in terms of
> allocation.

To me, unnecessary memory bookkeeping is some of the most distracting
code to have. Still, if you think it's likely for the tables to be of
variable size in the future, then it's reasonable to allocate them
dynamically, I suppose. I will observe that just because two different
versions of svndiff use different table sizes, that doesn't mean you
can't use a fixed-size array; it just means the array has to be large
enough to cover all of the possibilities. The wasted space is probably
not an issue unless some version wants to use a huge buffer.

(At any rate, in keeping with the pool usage style Greg Stein has been
trying to enforce, we should probably not create a separate pool for the
cache allocations. "Self-managing" types which contain their own pools
are currently out of fashion, even though we still have a number of them
in the code.)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:08 2006

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.