Not yet

Actually I am not sure what a microbenchmark would look like in this case as I've removed the old methods and replaced them with a single one that extracts the necessary data in one pass.

@franz1981 how do you usually handle cases like this? Moreover, do you think a microbenchmark is even necessary in this case?

That's how I do it: https://github.com/franz1981/java-puzzles/blob/74d60bbb8639ccbc1158046ce8d5575720bca96c/src/main/java/red/hat/puzzles/cstatic/StaticInt.java

You can use -prof jfr:dir=profile-results;configName=jfr-profile.jfc

And use JMC to read the class loading events and compilation events or just using both -prof cl -prof comp instead (which are easier to use tbh)

These are very tricky benchmarks since:

• class loading can be dominated by I/O files so having enough forks is necessary to make it happen on the OS page cache - but it means it will be less representative of a real use case since the OS page cache would appear like a super fast disk (whilst is not what happen on containers with rate limited disks i.e. AWS)
• beware whatever is loaded by JMH infra which can affect measurements: e.g. if what you want to benchmark is leading an expensive Java util class A, but the JMH infra does it too, it will make the code under test to appear faster, If it was the dominant factor, but maybe they same class won't be loaded in the real use case

Which means, make sure the effect you want to measure is big enough that observing it, reproduces it with fidelity and is not absorbed by the infrastructure cost

In this case what I think @tsegismont was asking for was just a comparison of the parsing from String

Here is what a CPU time flamegraph looks like currently:

And with this patched backported to 4.5.11 it looks like this:

It does seem however that this is causing more allocations so I'll see what I can do

I pushed an update and now things look rather nice.

Here is the CPU time flamegraph:

vs the original one:

And now the allocation flamegraph is also better, see:

vs the original one:

Ideally I would want this in Vert.x 4 as well :)

Actually I am not sure what a microbenchmark would look like in this case as I've removed the old methods and replaced them with a single one that extracts the necessary data in one pass.

It would have two methods comparing the code inside if (isLinux()) { ... } before and after the change.

I pushed an update and now things look rather nice.

Here is the CPU time flamegraph:

I'm not an expert but it seems both diagrams use AddressResolver init as the wide base. So the conclusion that performance has been improved is drawn from the number of samples ? (i.e 60 instead of 118)

So the conclusion that performance has been improved is drawn from the number of samples ? (i.e 60 instead of 118)

Correct.

I'm not an expert but it seems both diagrams use AddressResolver init as the wide base

I could have also used a base lower down the call stack that would show that AddressResolver#<clinit> is now narrower