←back to thread

One year after switching from Java to Go

(glasskube.dev)
257 points pmig | 2 comments | 18 Feb 25 16:55 UTC | HN request time: 0s | source
Show context
pseudoramble ◴[18 Feb 25 22:58 UTC] 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 ◴[18 Feb 25 23:07 UTC] 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 ◴[18 Feb 25 23:12 UTC] 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. xxs ◴[18 Feb 25 23:24 UTC] No.43096445[source]▶
> Spring devs say that some (a lot?) of the runtime reflection

It's a lot more than reflection, if it'd have been reflection alone - it'd be markedly better. (and yes, lots and lots can be optimized). Spring effectively:

  scans the classpath for resources - that includes jars, file system
  loads every single class matching the scanned directories as a byte array
  parses it in java (not by JVM) to check what annotations it has (it doesn't load  the classes actually)
  builds dependency tree
  enhances the previously loaded byte arrays, i.e. generates different byte code
  loads the newly enhanced classes and create instances (usually through standard reflection)
  makes calls like PostInit (life cycle)
  in some cases it uses the standard java reflection to set fields/call methods; in lots of cases java reflection is generating (and loading) a new class (byte code) to carry the process
all the steps above can be recorded on run time (or be a step in the build process) and let the JVM just load the classes organically.

as for the 100%, spring initialization is mostly single threaded - so likely you dont have many cpus dedicated to the java process. (or you meant just a single core 100%)

replies(1): >>43096825 #
2. jamesfinlayson ◴[19 Feb 25 00:06 UTC] No.43096825[source]▶
Ah okay - yeah I'm not across the internals at all.

And yeah I assume it's a single core, but definitely a heavy start.