• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Optimizing Java: When it's better to optimize?

 
Ranch Hand
Posts: 144
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Ben Evans, James Gough & Chris Newland,

Do you think it's possible to develop software with Java performance/optimization in mind, having that client specification and desires change over time during the development phase or it should be done mostly during a refactoring stage?

If not, how do I or my team can cope with optimization/performance during the development phase?
There are any approaches for this or it depends on the experience of the developers?

Thanks.
 
author
Posts: 67
10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I definitely think that you can start from some high-level loose (but still quantitative goals):

"The user wants to see the web page fully rendered on average no more than 500ms after the first byte has been received"

That's a performance requirement / story that can be written very early on - and once enough of the system has been written  (e.g. at integration test or system test) then it can be measured - and you can see how close you are to the goal. If you have sufficient instrumentation, you can see where the latency budget is being spent, and do some quick tidy-up performance work before the system is live.

However - beware over-optimization, benchmarking on systems that aren't similar to PROD and expecting too much of the overall performance to be dependent on code choices.

I sometimes say: "For most applications, it doesn't matter at all whether you choose a foreach loop or a stream". You might be able to concoct a microbench where you think you can see a difference, but in a real application, that difference will be swamped by aggregation effects and noise in the system.
 
Jorge Ruiz-Aquino
Ranch Hand
Posts: 144
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for your advice on specifications and metric recordings.

I'll keep these in my quote materials:

However - beware over-optimization, benchmarking on systems that aren't similar to PROD and expecting too much of the overall performance to be dependent on code choices.

I sometimes say: "For most applications, it doesn't matter at all whether you choose a foreach loop or a stream". You might be able to concoct a microbench where you think you can see a difference, but in a real application, that difference will be swamped by aggregation effects and noise in the system.



I have seen these aggregations and noise effects in real applications, as you said, Thank you for pointing that.
I've also seen newbie or even old-developers with bad practices introduce some logic that hurts the performance of the app.
 
author
Posts: 14
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Having spent a lot of time working with C++ and C++ developers the goal is to care about every fraction of performance that you get from a process. With C++ you can take this approach because the code you write is more closely translated to the instructions executed by the machine.

Java is very different. This diagram from the book show the different subsystems involved in the JVM. Your code goes from java -> byte code (using javacc) -> interpreted code -> potentially natively compiled code thanks to the Just in Time Compiler. The code is compiled at runtime based on it's current execution profile, meaning that it can be compiled in a different way by the same application and indeed can be compiled completely differently in another. You might find this article interesting.

One of the best things you can do for performance is to select the right algorithms and data structures (being aware when the business case changes the code may also need to change). The other is to write small methods (with tests ), the tests don't help performance initially but if you later make changes they can be used to validate the change.

It's worthwhile to keep performance in mind and have performance goals, but be careful trying to apply these too early on without an adequate profile.
 
Jim Gough
author
Posts: 14
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Diagram from the book can be found here: https://jpgough.github.io/assets/images/blog/oj/performance-landscape.png
 
Illustrator
Posts: 8
7
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here's the JVM internals diagram!
Opt-Java_WebPromo_v1-JVM.png
[Thumbnail for Opt-Java_WebPromo_v1-JVM.png]
JVM internals diagram from Optimizing Java
 
Jorge Ruiz-Aquino
Ranch Hand
Posts: 144
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you all.

That's a pretty nice article to read. I'll check the videos under "Talks" section.
I think this sort of matters need pictures/graphics to be understandable, at least for me.
Does the book include other images like that to explain issues?

Again, thanks for the resources you shared.

 
Anna Evans
Illustrator
Posts: 8
7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jorge,

Yes, there are quite a few illustrations throughout the book, as well as screenshots to show what you might expect to see from some of the tooling – it's one of the reasons the book has been produced in full colour. Some of the diagrams Ben and I have evolved over the years while developing training materials, others have been created specifically for this book.

(I definitely find it easier to grasp these sort of concepts when there are images as well as words... which is why I'm an illustrator!)
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic