41–50 of 205 posts
>Netflix observed a 20% increase of CPU usage on JDK 17 compared to JDK 8. This was mostly due to the improvements in the G1 garbage collector. Help me here, why do GC improvements cause CPU increase?
I think this is a 20% improved utilization of CPU, earlier app was memory-bound or/and GC was consuming CPU. Now app has 20% more CPU available. It should be doing correspondingly more work. This could definitely be written clearly.
>Netflix observed a 20% increase of CPU usage on JDK 17 compared to JDK 8. This was mostly due to the improvements in the G1 garbage collector. Help me here, why do GC improvements cause CPU increase?
In Java 8 (afaik) there were pretty much no generational or concurrent garbage collectors, so garbage collector would happen in a stop-the-world manner: all work gets put on a halt, garbage collection happens, then the work can resume.
If you have a better GC, you have shorter and less frequent needs to do a stop the world pause.
Hence the code can run on cpu for more time, getting you higher cpu usage.
Higher cpu usage is often actually good in situations like this: it means you're getting more work done with the same cpu/memory configuration.
Spring Boot and Spring cloud for backend & graphql for the win. ;-)
No, just no. Performance and debugging are just plain horrible. The spring team loves to force you into their automagic shit and this bean stuff is so annoying. You almost got no compile time safety in this stack. It's the bane of my existence. I'd like to know that a compiled program will run. That seems virtually impossible with java/spring boot.
Earlier quoted context omitted.
Most modern GCs trade off CPU usage and latency. Less latency means the CPU has to do more work on e.g. a separate thread to figure out what can be garbage collected. JDK 8 wouldn't have had the G1 collector (I think, or at least a really old version of that) and they would have probably been using one of the now deprecated garbage collectors that would be collecting less often but have a more open ended stop the wor…
The figure is about the overall improvement , not sure why that reads increase. On JDK 8 we are using G1 for our modern application stack, and we saw a reduction in CPU utilisation with the upgrade with few exceptions (saw what I believe is our first regression today: a busy wait in ForkJoinPool with parallel streams; fixed in 19 and later it seems). G1 has seen the greatest improvement from 8 to 17 compared to its c…
Yep. G1 in newer JDKs is very different from G1 in JDK 8, but Parallel GC has also seen very significant improvements: https://kstefanj.github.io/2021/11/24/gc-progress-8-17.html
Spring Boot and Spring cloud for backend & graphql for the win. ;-)
No, just no. Performance and debugging are just plain horrible. The spring team loves to force you into their automagic shit and this bean stuff is so annoying. You almost got no compile time safety in this stack. It's the bane of my existence. I'd like to know that a compiled program will run. That seems virtually impossible with java/spring boot.
Once you learn the annotation based configuration it also saves a lot of time.
The performance is valid but it will only keep improving.
Earlier quoted context omitted.
It's constantly sending requests from BE to FE - checking IP, checking watch time etc.
That shouldn't take that much CPU tbh, but if it does, it sounds like they have some optimization to do. I wonder if it's like DRM in video games, causing a lot of overhead.
I watch streams on youtube, twitch etc and everything is fine.
However whole CPU is flying to the moon if I will watch something on netflix.
Btw Chrome was pure a nightmare for CPU but Brave is better.
Spring Boot and Spring cloud for backend & graphql for the win. ;-)
No, just no. Performance and debugging are just plain horrible. The spring team loves to force you into their automagic shit and this bean stuff is so annoying. You almost got no compile time safety in this stack. It's the bane of my existence. I'd like to know that a compiled program will run. That seems virtually impossible with java/spring boot.
Spring Boot and Spring cloud for backend & graphql for the win. ;-)
No, just no. Performance and debugging are just plain horrible. The spring team loves to force you into their automagic shit and this bean stuff is so annoying. You almost got no compile time safety in this stack. It's the bane of my existence. I'd like to know that a compiled program will run. That seems virtually impossible with java/spring boot.