Places to potentially find startup performance improvements

[geoand]

Description

• quarkus.uuid provided eagerly -> Produce quarkus.uuid lazily #45434
• application.properties / META-INF/microprofile-config.properties reading from classpath
  • Discussed with @radcortez here
  • Empirically verified that this would make a measurable impact
• ExtLogRecord looking up HostName and Process related data that aren't needed by the default logging pattern
• Offload Vertx / Netty class loading to other thread (like we do for DefaultChannelId)
• Context Propagation config handling -> Use empty default values when building no-op CP instance #45438
• Vert.x /etc/resolv.conf handling -> Use simple parser instead of regex for parsing resolv.conf eclipse-vertx/vert.x#5439

These ideas come from looking at this flamegraph

[franz1981]

@geoand I would add #43022 as well
since, with 2 or more event loops, the "new" concurrency allowed by the CL make it load more byte[] and fail on definition later on during class loading. This is both impacting memory and time.

[geoand]

ExtLogRecord looking up HostName and Process related data that aren't needed by the default logging pattern

@dmlloyd I wanted to move the relevant fields into a holder, but the need to support serialization prevents this approach.

[franz1981]

Another "big" (relatively) one @geoand is this -> smallrye/smallrye-common#370

this is very easy: just use 64 bytes cache line as other known projects does i.e. https://github.com/ziglang/zig/blob/master/lib/std/atomic.zig#L429 (which for both arm and x86 uses 2 * 64 bytes due to jbossas/jboss-threads#191)

We are reading from a proc file, in linux, performing both a syscall, parsing and creating garbage for such. It looks an easy win with low impact.

[geoand]

Just for posterity, the comment above should be handled by jbossas/jboss-threads#216

[radcortez]

It also has to be handled here:
https://github.com/smallrye/smallrye-common/blob/e43dfdf9b512185fd8c96ad720fcd4070ff12030/cpu/src/main/java/io/smallrye/common/cpu/CacheInfo.java#L80-L155

I did a quick return with the expected bytes, and on my Mac I noticed around 20 ms improvement in the JVM startup time.

[radcortez]

• ExtLogRecord looking up HostName and Process related data that aren't needed by the default logging pattern

What's the plan with HostName? After #41664, I'm getting 2 / 3 ms increase in the native image startup time.

[geoand]

It also has to be handled here: https://github.com/smallrye/smallrye-common/blob/e43dfdf9b512185fd8c96ad720fcd4070ff12030/cpu/src/main/java/io/smallrye/common/cpu/CacheInfo.java#L80-L155

I did a quick return with the expected bytes, and on my Mac I noticed around 20 ms improvement in the JVM startup time.

With the change from @franz1981, I think that CacheInfo won't be used/loaded at all in Quarkus. Did you see otherwise @radcortez ?

[geoand]

• ExtLogRecord looking up HostName and Process related data that aren't needed by the default logging pattern

What's the plan with HostName? After #41664, I'm getting 2 / 3 ms increase in the native image startup time.

I was hoping @dmlloyd has an idea as my original idea won't work.

[Sanne]

Offload Vertx / Netty class loading to other thread (like we do for DefaultChannelId)

Regarding this, we also do something for async initialize the JPA components. Should we have a unified/consistent approach? Just flagging it for awareness.

[geoand]

Regarding this, we also do something for async initialize the JPA components. Should we have a unified/consistent approach? Just flagging it for awareness.

Right, that thought did cross my mind

[dmlloyd]

• ExtLogRecord looking up HostName and Process related data that aren't needed by the default logging pattern

What's the plan with HostName? After #41664, I'm getting 2 / 3 ms increase in the native image startup time.

2/3 ms for host name or for process name? or both? That seems like a pretty crazy number. Perhaps for host name, we should track the time and print a warning if it seems like DNS may be misconfigured (check your /etc/hosts). The user also has the option of setting the HOSTNAME environment variable, which bypasses some work.

[geoand]

application.properties / META-INF/microprofile-config.properties reading from classpath

@radcortez do you plan on taking this one on soon? Asking because it definitely has a measurable impact.

[geoand]

ExtLogRecord looking up HostName and Process related data that aren't needed by the default logging pattern

@dmlloyd any ideas about tackling this one?

[radcortez]

application.properties / META-INF/microprofile-config.properties reading from classpath

@radcortez do you plan on taking this one on soon? Asking because it definitely has a measurable impact.

Yes, but only next week.

[geoand]

🙏

[dmlloyd]

ExtLogRecord looking up HostName and Process related data that aren't needed by the default logging pattern

@dmlloyd any ideas about tackling this one?

I did mention this:

What's the plan with HostName? After #41664, I'm getting 2 / 3 ms increase in the native image startup time.

2/3 ms for host name or for process name? or both? That seems like a pretty crazy number. Perhaps for host name, we should track the time and print a warning if it seems like DNS may be misconfigured (check your /etc/hosts). The user also has the option of setting the HOSTNAME environment variable, which bypasses some work.

Another idea is to add access to the gethostname system call in Java 22/23/24+ using FFM which might be fast (it does rely on method handle setup though, and a couple of other things).

[geoand]

But if I'm not mistaken, the default Quarkus logging pattern does not use the hostname (or any process info), so wouldn't it be better if we didn't try to load it eagerly?

[dmlloyd]

That is an option. But I think it works be best to understand why it is slow and see if it can be fixed before jumping to that.

[geoand]

On my machine (Linux), it definitely does not take nearly as long as @radcortez, but both the call to HostName and Process are noticeable:

Looking at the flamegraph and the code, there don't seem to be any obvious wins for my case.
Sure setting the system properties would avoid the hostname cost, by I don't see why one would have to do that. Getting rid of the method references might also help a bit, but we are still paying the (admittedly small) cost for something that in most cases will not be used