Hi again,
isn' there any chance for a renaming?
I think, e.g.,
+return unsigned(b[n]) | (unsigned(b[n + 1]) << 8);
would be much more writeable + readable than ...
+return Byte.toUnsignedInt(b[n]) | (Byte.toUnsignedInt(b[n + 1]) <<
8);
In 2nd case, static import is not p
Thanks Sherman; given the at most marginal performance cost, I'll push
the changes in the next day or two.
-Joe
On 02/06/2012 05:02 PM, Xueming Shen wrote:
Joe,
I did some non-scientific measure of the performance. test1() is to
measure the change
in a real "listing" operation on a ZipInput
Joe,
I did some non-scientific measure of the performance. test1() is to
measure the change
in a real "listing" operation on a ZipInputStream and test2() is a pure
access on the byte[]
directly. I don't see any significant difference on performance in both
-client and -server
vm. I would assu
Sherman, thanks for offering to investigate the performance impact, if
any, of this change.
-Joe
PS All the jar/zip regression tests pass with this change.
On 01/26/2012 09:52 AM, Xueming Shen wrote:
Joe,
The changes look fine. However I have the same performance concern in
cases that the vm
Hello,
On 1/26/2012 9:13 AM, Ulf Zibis wrote:
Am 26.01.2012 17:11, schrieb Roger Riggs:
[snip]
Its unfortunate that between the method name and need to qualify
with the class (or use static imports) that the code is longer and
not always clearer.
+1
- static import could become ambiguou
Am 26.01.2012 17:11, schrieb Roger Riggs:
Is there any performance impact of the method call vs the &0xff?
Hotspot will in-line the code but for VMs with less sophisticated
optimizations it will be a net loss.
+1
At least in interpreter and maybe -client compiler the new code would have
perform
