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 On Tuesday, July 7, 2020 at 10:46:31 AM UTC+2 [email protected] wrote: > 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 > > > On Tue, 7 Jul 2020 at 10:15, [email protected] <[email protected]> wrote: > >> 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 >> >> >> >> >> >> >> >> -- >> 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 [email protected]. >> To view this discussion on the web, visit >> https://groups.google.com/d/msgid/mechanical-sympathy/369b413d-d101-43cf-bbc0-2f8af887a3d4n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/mechanical-sympathy/369b413d-d101-43cf-bbc0-2f8af887a3d4n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/27b66f26-663a-4769-b685-f4056edbe6ccn%40googlegroups.com.
