On 08/04/2019 15:55, Aleksey Shipilev wrote:
> Why introduce this complexity to begin with? That's my argument. The
> complication of this code gives
> us almost nothing in return, why make the change? Without the compelling
> reason to do it, all this
> is just a runaway "hold my beer" micro-optimization exercise, which is fun
> and instructional, but
> should not be pushed to the actual JDK. In other words, just because we *can*
> it does not follow
> that we *should*.
I think that is a good argument. The vast majority of apps are not going
to see any performance hit from the relatively rare occurrence of zero
hashes. Those rare apps which see a lot of them will still only see a
marginal performance hit.
n.b. I say marginal because I believe that an app which sees enough zero
hashes for the effect not to be marginal (i.e.it is not doing much else)
is probably not an app but a Trojan horse of a (micro?) benchmark
masquerading as an app (timeo Danaos et lecti marcae ferentes -- pardon
my Latin and don't ask what those notches on the couch might mean ;-).
So, I agree with Aleksey that adding a potential maintenance headache
for this little gain is not the right trade-off.
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
