Java UI performance WSL vs Windows

[va...@lem-one.nl]

Hi,

I recently got involved to get an existing Java Swing UI to perform better. I have incrementally  been making minor changes till now and getting improvements.

Since we are mostly developing on Linux/OSx boxes we were already aware that there is a significant difference in performance between these, where Windows would be least responsive.  

At some point we decided to run a crazy experiment and just run our Java UI on WSL (Ubuntu), on a Windows machine side by side with the same Java UI on plain Windows.

It turns out that the WSL UI outperforms the Windows UI by miles.

I want to start digging into details as soon as I have time but I was wondering if someone has any intuition on what's going on here. I would not expect a performance gain by adding an extra level of indirection.

Vasco

 

[Luiz Fernando Teston]

Hi Vasco,

You need to measure where the code is spending time with, otherwise it will be guessing. Keep that in mind and use any tool you are familiar with that can get measurements of your execution. I suppose the target here is to measure the latency of each part of your stacktrace over time.  A profiler or APM are the best options and we have good open source options for those.

What I would do in your place is attach a profiler on your application while performing the slow actions on the application, and then check the profiler data and tackle specific parts of the code. It is likely the slowness is not on the user interface code, but again, I am guessing now and guessing is no good.

A profiler that provides flame graphs will be visually easier to find out where the time is spent. A few suggestions I have:

- Read a bit on http://www.brendangregg.com/flamegraphs.html  and try one of the tools bellow:

- easy option: https://glowroot.org/ - will be easy enough to configure and attach and check graphs. Explore it if you're not familiar with profilers or APMs.

- not-so-easy-but-better: https://github.com/jvm-profiling-tools/async-profiler - will provide better resolution, less performance impact on your application at a cost of a bit less user friendly approach.

When you see a big thing on the flamegraph, it should point to which part of the application code it is spending time with. Then  you work where the problem really is. I've been using this approach to find production spots that are slow with minimum effort.

Good luck on your profiling!

Cheers

Luiz

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/369b413d-d101-43cf-bbc0-2f8af887a3d4n%40googlegroups.com.

[Simone Bordet]

Hi,

Make sure the Java2D rendering pipeline you are using is the same across tests.

OpenJDK is based on Marlin (https://openjdk.java.net/jeps/265), but
Oracle's JDK may be different, and same for other vendors.

See also: https://www.azul.com/blog/performance-rendered-visual/

--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

[va...@lem-one.nl]

Luiz,

Thanks for the feedback. I am aware of the task in front of me when it comes to possibly pinpointing it. My question was more int a general sense since it is such a highly unintuitive observation.

Vasco

[va...@lem-one.nl]

Simone,

JDK's are identical. It is just the extra layer on indirection that makes it faster,

Vasco