Our application has around 500 entity classes, And after upgrading from hibernate 5.2 to the latest (Currently 7.1 though the issue has persisted through all later versions), The Session factory initialization time increased to 4+ minutes (From the previous under 1 minute)…
We noticed that as we reduce on the entities, The associated initialization time goes down too, Which points to (suspectingly) byte code enhancement and proxy generation…
As documented, Previous versions used javassist while these laters are using bytebuddy, Which is turning out to be slower - As you can imagine, In a desktop application you can’t really display a splash screen for 4+ minutes waiting for the Session factory to initialize…
What we can’t test now is trying to switch back to javassist since the hibernate.bytecode.provider configuration setting is now totally ignored, Our request is to support this setting since different applications have different requirements, That’s the point of the ByecodeProvider contract…
Different developers can always come up with more efficient implementations and it’s just ‘not wise’ to lock them out, Bytebuddy can always be the default BUT there should be a way to switch basing on one’s application requirements, Besides an application (like our case) may already be using a different implementation (from Bytebuddy) in other parts of the project…
Like I already told you here, there can be many different reasons for this behavior.
Clearly, the boot time is related to the amount of entities, because the more entities Hibernate ORM has to analyze, the more processing needs to happen.
You can customize BytecodeProvider if you want, but I doubt that it has to do with that. The easiest way to figure this out, is to just use build time bytecode enhancement and see if that improves your startup time.
The configuration property hibernate.bytecode.provider is deprecated, And some source files suggest you auto-detect the one on the classpath, Which may still lead to not selecting the intended one…
Thing is, The same code used to run well on hibernate 5.2, The Session factory used to take less time during initialization…
Anyway, How can we change the bytecode provider to javassist? It has proven to be faster in other parts of the project, And even consumes less memory…
The configuration property hibernate.bytecode.provider is deprecated, And some source files suggest you auto-detect the one on the classpath, Which may still lead to not selecting the intended one…
True, depending on your setup/configuration, it may be that a different class is being discovered. You can configure that the TCCL takes precedence.
You can also register the service through the ServiceInitiator SPI that is also discovered through the Java ServiceLoader mechanism. That way, you don’t depend on the class path order and can simply overwrite the default service.
Thing is, The same code used to run well on hibernate 5.2, The Session factory used to take less time during initialization…
I don’t know what you expect. Hibernate ORM 5.2 was released 9 years ago and obviously, a lot has changed since then. The boot process was changed significantly and there were reports from people who actually put in the effort to analyze what is going on or provide reproducers for startup time degradation. We identified a couple of issues and fixed them, now these users are happy again.
If you are willing to put in the effort and help us understand what it is exactly that makes your startup slower, we can look into it, but just saying that javassist is faster without providing proof is not going to help. If you have e.g. like flamegraphs showing how much CPU is spent in bytebuddy classes or something similar, we can look at bottlenecks and see if there is a way to improve things.
Anyway, How can we change the bytecode provider to javassist? It has proven to be faster in other parts of the project, And even consumes less memory…
First, you have to implement a custom bytecode provider based on javassist yourself and then you can plug it in via ServiceInitiator.
