4 ms·

HotSpot took 2 decades to get to its current performance, and while its JITted performance is good, for desktop apps cold boot performance is at least as import

by dtech 5y ago

HotSpot took 2 decades to get to its current performance, and while its JITted performance is good, for desktop apps cold boot performance is at least as important.

jjoonathan 5y ago
Moore's law didn't hurt either. I think there's a big confounding factor, though: people self-select into platforms depending on what they care about. People who self-selected into Java didn't value perf. They were then inclined to ignore their own performance problems for the same reason they selected Java: they didn't value perf. That's why so many Java GUIs chug so hard, even today, when it really can't be blamed on Java itself. For instance, Ghidra: if you leave a filter active in a GUI box and run an analysis tool, sometimes the runtime of the tool explodes from minutes to days because it refreshes the GUI after each of the zillion model tweaks the analysis tool needs to perform. It's not Java's fault that nobody put in the code to throttle GUI updates, but the same list of priorities that led the creators to choose Java also led them to ignore a massive perf landmine sitting in the middle of the road for all to see and occasionally hit. I recently fired up LibreOffice Sheets to see how it compared to Google Sheets. It took four entire seconds to switch to editing mode in a cell. Every time, not just the first. If I were to root cause the issue, I'm sure it wouldn't be Java's fault -- but I bet that the same priorities that led the project to choose Java led them to ignore a four second stall in their most critical user interaction path. Both of these projects are free, so I'm not upset about getting what I paid for, but I have plenty examples from corporate Java GUIs as well. I don't think this is a Java problem, I think it's a priorities-held-by-Java-programmers problem.
- lawl 5y ago
  Reminds me of this post: https://nibblestew.blogspot.com/2020/03/its-not-what-programming-languages-do.html?m=1 https://nibblestew.blogspot.com/2020/03/its-not-what-program... In the case of java though in my opinion the problems start at the std library that sometimes forces you to write really inefficient code, or reimplement everything yourself.
- zmmmmm 5y ago
  > I recently fired up LibreOffice Sheets to see how it compared to Google Sheets. It took four entire seconds to switch to editing mode in a cell. Every time, not just the first. If I were to root cause the issue, I'm sure it wouldn't be Java's fault -- but I bet that the same priorities that led the project to choose Java led them to ignore a four second stall in their most critical user interaction path That's a slightly confusing comment because while it does integrate it in some components, very little of LibreOffice is written in Java. From what I understand, the core of it is all written in C++ and it's often held up as a canonical example of what happens when a giant C++ codebase gets out of control and doesn't manage complexity well.
  - jjoonathan 5y ago
    Well, the stack overflows through the years seem to resolve similar issues by pinning the JRE version, so I assumed it had something to do with it. Sounds like that might have been a bad assumption. Either way, I never tracked it down. Plenty of options for spreadsheets these days.

by dtech 5y ago

HotSpot took 2 decades to get to its current performance, and while its JITted performance is good, for desktop apps cold boot performance is at least as important.

jjoonathan 5y ago

Moore's law didn't hurt either. I think there's a big confounding factor, though: people self-select into platforms depending on what they care about. People who self-selected into Java didn't value perf. They were then inclined to ignore their own performance problems for the same reason they selected Java: they didn't value perf. That's why so many Java GUIs chug so hard, even today, when it really can't be blamed on Java itself. For instance, Ghidra: if you leave a filter active in a GUI box and run an analysis tool, sometimes the runtime of the tool explodes from minutes to days because it refreshes the GUI after each of the zillion model tweaks the analysis tool needs to perform. It's not Java's fault that nobody put in the code to throttle GUI updates, but the same list of priorities that led the creators to choose Java also led them to ignore a massive perf landmine sitting in the middle of the road for all to see and occasionally hit. I recently fired up LibreOffice Sheets to see how it compared to Google Sheets. It took four entire seconds to switch to editing mode in a cell. Every time, not just the first. If I were to root cause the issue, I'm sure it wouldn't be Java's fault -- but I bet that the same priorities that led the project to choose Java led them to ignore a four second stall in their most critical user interaction path. Both of these projects are free, so I'm not upset about getting what I paid for, but I have plenty examples from corporate Java GUIs as well. I don't think this is a Java problem, I think it's a priorities-held-by-Java-programmers problem.

lawl 5y ago
Reminds me of this post: https://nibblestew.blogspot.com/2020/03/its-not-what-programming-languages-do.html?m=1 https://nibblestew.blogspot.com/2020/03/its-not-what-program... In the case of java though in my opinion the problems start at the std library that sometimes forces you to write really inefficient code, or reimplement everything yourself.
zmmmmm 5y ago
> I recently fired up LibreOffice Sheets to see how it compared to Google Sheets. It took four entire seconds to switch to editing mode in a cell. Every time, not just the first. If I were to root cause the issue, I'm sure it wouldn't be Java's fault -- but I bet that the same priorities that led the project to choose Java led them to ignore a four second stall in their most critical user interaction path That's a slightly confusing comment because while it does integrate it in some components, very little of LibreOffice is written in Java. From what I understand, the core of it is all written in C++ and it's often held up as a canonical example of what happens when a giant C++ codebase gets out of control and doesn't manage complexity well.
- jjoonathan 5y ago
  Well, the stack overflows through the years seem to resolve similar issues by pinning the JRE version, so I assumed it had something to do with it. Sounds like that might have been a bad assumption. Either way, I never tracked it down. Plenty of options for spreadsheets these days.