ArcContainerImpl could skip SecureRandom initialization

[Sanne]

Description
The 'ArcContainerImpl' is eagerly initializing an uuid field, which requires a Secure random call; according to flamegraphs including native time, this is taking 30% of the time it takes to boot Arc so it would be nice to skip it.

Implementation ideas
The uuid field seems only necessary for toString(). I think it could be lazily initialized, I'm not sure what expectation there is in terms of having the same uuid (or not) of the same app when it's build as native.

I suppose it should mimick the JVM semantics, which implies lazy initialization would actually be better.

[mkouba]

this is taking 30% of the time it takes to boot Arc so it would be nice to skip it.

Interesting. How much time does this 30% represent?

The uuid field seems only necessary for toString().

Yes, it is. Although it could be accessible through the ArcContainer interface in the future. The idea is to have a unique identifier of a container instance. On the other hand, we don't support running parallel container instances ATM and so it's mostly useful for debugging. In theory, we could use a simple static counter as well.

[mkouba]

@Sanne pls provide more info...

[Sanne]

hi @mkouba - to provide more details I'll need to run those metrics again; it takes me quite some time and won't be able to do it this week.

Of course the win isn't very high in absoulte terms, as Arc boots quite fast - we're talking about milliseconds. But considering the spirit of Quarkus if this uuid isn't used I'd just avoid it: it's not only about time but also about including / loading the securerandom related classes - and the system code necessary to support these.

I'd remove this UUID as it seems very simple to do; you could just re-introduce it in case of need?
Otherwise if you think it's needed, lets' move on and close this.

[mkouba]

@Sanne Ok. No need to run the tests again. I've already fixed this in #4676.