On Tuesday, October 18, 2016, Martin Buchholz <marti...@google.com> wrote:
> > > On Tue, Oct 18, 2016 at 4:00 PM, Vitaly Davidovich <vita...@gmail.com > <javascript:_e(%7B%7D,'cvml','vita...@gmail.com');>> wrote: > >> >>> > * Change in allocation/capacity policy. >>> > >>> > The removal of the power-of-two restriction, and applying a 1.5x growth >>> > factor (same as ArrayList) seems sensible. Does this mean that the >>> ability >>> > to compute the proper array index by using x & (length-1) wasn't worth >>> it? >>> > Or at least not worth the extra tail wastage? >>> > >>> >>> There's no integer division to optimize, as with hash tables. >> >> But it does add some new branches, doesn't it? Potentially branches that >> aren't taken prior to JIT compilation, but taken later = deopt. >> > > If it's a smidgeon slower, I don't care that much; improvement in > flexibility and scalability are more important. > Well, others may :). I'm not saying it's slower, I don't know, but you're dismissing that possibility a bit too quickly, methinks. > > Of course, I do care about algorithmic improvements to e.g. removeIf > Sure, no debate. > > >> Curious if you ran some benchmarks on ArrayDeque. >> > > Not yet. Who would like to show how slow the code is? > > >> Also, some odd stylistic things, such as: >> >> while (s == (capacity = (elements = this.elements).length)) >> >> Is this an attempt to help the JIT or something? >> >> "jsr166 style" - makes it easy on javac and the JIT, if not for humans. > In some of the cases here, I'd consider it a significant JIT failure if the "jsr166 style" makes a difference (I'm not sure how this makes a difference to javac - did you mean interpreter?). Is this jsr style a carryover from long ago? Maybe it needs to be reconsidered. The code clarity isn't terrible, but it would be unfortunate to do this in simple cases where the compiler ought to handle it just fine - does it not? -- Sent from my phone
