From: Yann Simon <yann.simon.fr@gmail.com>
Date: Mon, 23 Mar 2009 10:36:50 GMT
Subject: Re: [PATCH JGIT] Method invokes inefficient Number constructor; use static valueOf instead
Message-ID: <551f769b0903230336v116ce40bn8ce6a1a28b997fd@mail.gmail.com>
In-Reply-To: <20090319154958.GP23521@spearce.org>

2009/3/19 Shawn O. Pearce <spearce@spearce.org>:
> Why I box with new Long() over Long.valueOf():
>
>  The standard only requires -128..127 to be cached.  A JRE can
>  cache value outside of this range if it chooses, but long has a
>  huge range, its unlikely to cache much beyond this required region.
>
>  Most pack files are in the 10 MB...100+ MB range.  Most objects
>  take more than 100 bytes in a pack, even compressed delta encoded.
>  Thus any object after the first is going to have its offset outside
>  of the cached range.
>
>  In other words, why waste the CPU cycles on the "cached range
>  bounds check" when I'm always going to fail and allocate.  I might
>  as well just allocate
>
>  These sections of code are rather performance critical for the
>  indexing phase of a pack receive, on either side of a connection.
>  I need to shave even more instructions out of the critical paths,
>  as its not fast enough as-is.  Using new Long() is quicker than
>  using Long.valueOf(), so new Long() it is.

It makes sense.
Thank you for the explanation.

Yann