On 15 Feb 2002, Greg Hudson wrote:
> 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
> complexity.
I was actually quite surprised at the amount of savings.
But then i figured out that most integers end up in the 2 byte range, and
this makes them end up in the one byte range.
So as long as you can keep the size of the modes down to about 3 bits,
so you can merge it with offset without causing too many to go back up
to 2 bytes, you win quite a lot of bytes. If you encode mode on it's own,
as vcdiff does, you don't save enough bytes to make it a win overall,
because you need to save 2 bytes per integer for the 1 byte overhead of
mode to make it a win. Since most integers are 2 bytes, this is just not
possible.
>
> > 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.
No, my apologies if I was a little harsh or came off the wrong way.
Long day and all that.
>
> > > 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.
No worries, I made them fixed size. There are a few small changes
i'm going to make to the cache to improve efficiency, and i forgot i had
already made it ignore duplicates. These changes make it incompatible
with vcdiff anyway.
---------------------------------------------------------------------
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