From: Sverre Rabbelier <srabbelier@gmail.com>
Date: Fri, 12 Dec 2008 15:50:32 GMT
Subject: Re: [JGIT PATCH 03/15] Add IntList as a more efficient representation of List<Integer>
Message-ID: <bd6139dc0812120750j19b4d56an24b9c52a3ca60f20@mail.gmail.com>
In-Reply-To: <20081212154115.GO32487@spearce.org>

On Fri, Dec 12, 2008 at 16:41, Shawn O. Pearce <spearce@spearce.org> wrote:
> If you'd like to send a patch to change it, I'll apply it.  But I
> don't think its worth my time to make this toString() more efficient.

I mainly mentioned it because it's in a Class meant to be more optimal
than what Java ships with, but I agree with your reasoning that this
toString is not part of what needs to be optimized.

> Other areas of JGit I do try to micro-optimize, because they are
> right smack in the middle of the critical paths.

Hehe, I very much agree with not optimizing prematurely, and if you do
optimize to go for it all the way.

> E.g. look at ObjectId.equals(byte[],int,byte[],int). I hand-unrolled
> the memcmp loop because the JIT on x86 does *soooo* much better
> when the code is spelled out:

<code snipped>

Kind of sad that you have to write this kind of code if you want good
performance, ah well, perhaps someday... (import java.lang.optimized
;) ).

> This block is in the critical path for any tree diff code, in
> particular for a "git log -- a/" sort of operation.  Its used
> to compare the SHA-1s from two different tree records to see if
> they differ.  Not unrolling this was a huge penalty.

I reckon that is done a lot :). Ashame the JRE can't do that kind of
optimization for you. e.g., if you do:
for(int i = 0; i < constant; i++) {
  some_code;
}

-- 
Cheers,

Sverre Rabbelier