0

I have been using java lambdas in place of normal inline declarations in our java ui code thinking that it is just shorter and more concise syntax. But have not seen any specs indicating this and the aws lambda service seems to dominate the search results.

I came across this site which shows how much underlying provision javac puts into a lambda declaration and would like to know if I am actually adversely affecting runtime or memory usage performance in anyway for using java lambda syntax over the pre-lambda approach when doing inline calls.

Our implementation uses jre 8.

For example using:

final ActionListener cancelButtonListener = (final ActionEvent ae) -> {
    // implementation w references to static or parent class member. ae argument is not referenced.
};

instead of

final ActionListener cancelButtonListener = new ActionListener() {
    @Override
    public void actionPerformed(final ActionEvent e) {
        // implementation w references to static or parent class member.  ae argument is not referenced.
    }
};

and

SwingUtilities.invokeLater(() -> {
    // implementation w references to static or parent class member.
});

instead of

StringUtilities.invokeLater(new Runnable() {
    @Override
    public void run() {
        // implementation w references to static or parent class member.
    }
});

Found a related post here. Also have found indicators that some lambdas will be compiled into byte code at runtime. I feel like my inline to lambda conversion should not affect performance would like to know what this community thinks.

simgineer
  • 1,754
  • 2
  • 22
  • 49
  • 1
    "would like to know if I am actually adversely affecting runtime or memory usage performance" - did you **try using it**, and profiling the memory usage and timing results? – Karl Knechtel May 15 '23 at 19:38
  • @Karl Not in an isolated environment there are a lot of other changes in the current test batch we are doing so it would take sometime to isolate and profile just the lambda changes. – simgineer May 15 '23 at 19:48
  • 3
    Short answer: lambdas are just as fast to capture and execute as inner classes, sometimes faster. Don't worry about it; write clear maintainable code. – Brian Goetz May 15 '23 at 23:46
  • @BrianGoetz do you think there is any chance that my lambda usage might trigger runtime compilation of the bytecode? It looks like the advantage of non lambda inline is that it's guaranteed that type bytecode is generated at compile time. Greatly appreciate your feedback. – simgineer May 16 '23 at 01:53
  • And? Generating bytecode is cheap. And only has to be done once. Otoh, if you do that during compile time, you have to read the bytes from disk, which might be slower. Related quote from Donald Knuth: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%". – Johannes Kuhn May 16 '23 at 02:24
  • 2
    Letting aside [the very first lambda expression of the entire runtime](https://stackoverflow.com/q/34585444/2711488), generating bytecode will be faster than loading the precompiled bytecode from the external storage, in most cases. And that’s *today*; future versions might not need to generate bytecode to construct the binding. Since this is done by the runtime, you will get such improvements for free. – Holger May 16 '23 at 13:11

0 Answers0