[jamesfinlayson]

> 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.

[xxs]

> 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%)

[jamesfinlayson]

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.

[trallnag]

This makes recycling nodes, be it ECS or Kubernetes nodes, that run tons of Spring apps, a huge pain.