←back to thread

257 points pmig | 1 comments | | HN request time: 0.368s | source
Show context
pseudoramble ◴[] No.43096211[source]
I’ve been out of the Java scene for a really long time, but will be coming back to it soon. I’m curious - these performance issues described here, are they inherit to how Java itself? Is it baggage from Spring/Boot? Are there ways to get more bang for the buck with some careful choices in a system like this?

The closest I’ve done to Java recently is C#, which I think may have similar challenges, but overall didn’t seem quite as bad if you avoided lots of framework extras. It also wasn’t something I was digging into deeply though, so perhaps I’m mistaken.

replies(6): >>43096295 #>>43096314 #>>43096318 #>>43096420 #>>43096427 #>>43100389 #
xxs ◴[] No.43096295[source]
Spring by far - Spring is effectively a build tool running at run time (scanning, enhance, code generation, etc.) - most of it is just startup as JVM does a decent job at optimizing the cruft. In most cases the boot times don't matter, though - at least for most people, esp. when it comes to production. (it's mostly developers time wasted)

I have some personal experience optimizing Spring to record previous runs and effectively cache resolution and code generation, etc. for massive boot latency improvements. Never got around contributing it back, though (not a real spring user)

replies(1): >>43096339 #
jamesfinlayson ◴[] No.43096339[source]
> most of it is just startup

Yep, I have some Spring code in AWS ECS and it hits 100% CPU usage on start-up before dropping back to 1.5% when idling (this is with 1 vCPU I think).

But yeah I remember reading one of the Spring devs say that some (a lot?) of the runtime reflection could be done at compile time but isn't.

replies(2): >>43096445 #>>43102661 #
1. trallnag ◴[] No.43102661[source]
This makes recycling nodes, be it ECS or Kubernetes nodes, that run tons of Spring apps, a huge pain.