On 3/10/19 9:19 PM, Martin Buchholz wrote:
We should stop discussing this here, but ...
... I think that we really should, but ...
On Sun, Mar 10, 2019 at 1:51 AM Peter Levart <peter.lev...@gmail.com
<mailto:peter.lev...@gmail.com>> wrote:
In this particular case, this is not true. A lambda that captures no
local or instance state is lazily constructed just once (when the
lambda
expression is 1st evaluated) and then it is used as a "local"
constant.
The performance model of this statement:
Objects.requireNonNullElements(defensiveCopy, i->
"stackTrace[" + i
+ "]");
Is exactly the same as the performance model of this combo:
static class Holder {
static final IntFunction<String> messageSupplier = i->
"stackTrace[" + i + "]";
}
I think that one is too expensive!
Initialization-on-demand holder idiom requires adding an entry to a
jar file and classload at runtime,
and causes some overhead in every single java program, even those that
don't load the class.
(one of the things improved by lambdas!)
Yes, I was trying to present the equivalence of performance models of
warmed-up code. Inline lambda doesn't require any new entries in jar
files, but it has some "initialization" overhead, that's true.
// ...and then in code:
Objects.requireNonNullElements(defensiveCopy,
Holder.messageSupplier);
The code in requireNonNullElements contains the same loop and the
same
"if" as the original loop and if statement, so the performance is the
same as "that "if" statement". There's even a potential to introduce
further optimization if such logic is extracted into a method as
opposed
to writing in-line loops with ifs (for example with some bulk
comparison
intrinsified logic) so there is even a potential to "beat" that "if"
statement...
Users shouldn't have to extract code into methods ("outlining") to get
the JIT to optimize.
No, and this is not the goal here. The original intent of Joe's patch
is to reduce boilerplate while not worsening the (warmed-up?)
performance at the same time. I think that the deciding factor about
introducing such method should be the frequency of occurrence of such
programming pattern in real code. Would introduction and use of such
method be worth it on the global scale in the short run?
As it turns out, inspecting the code of java.base module, for example,
shows that there are some places where such method could be of use, but
not enough to warrant its introduction. There are quite a few places
where an array or an Iterable is iterated and elements checked for
non-nullness, but those loops usually contain other logic too, so It
seems that this concrete "if" will stay where it is.
Regards, Peter
13 years later, the "easy" JIT bug
JDK-6445664
Eliminate remaining performance penalty for using assert
still isn't fixed.
