Hi Christian,
I don't like "apparently" when talking about performances :).
I would advise to use async profiler (
https://github.com/jvm-profiling-tools/async-profiler, also see
https://github.com/quarkusio/quarkus/blob/master/TROUBLESHOOTING.md to
learn more on how to use it) to try to understand what's going wrong and
how we could improve things.
I remember things were very slow with the initial ByteBuddy implementation
Rafael did and we got much better results by caching the ByteBuddy
transformations. In particular the calls to the ByteBuddy DSL are quite
expensive in terms of allocations because they are creating a ton of
objects.
Once we have some profiling results, we can talk.
--
Guillaume
On Tue, Aug 4, 2020 at 5:26 PM Christian Beikov <christian.beikov(a)gmail.com>
wrote:
I'm moving this discussion from Zulip to the mailing list as
Rafael does
not seem to be on Zulip. Here a little context:
> Does anyone know if there is a known performance issue with Bytebuddy
during boot in 5.4? I noticed that 5.4 takes about 25%, sometimes up to
30% percent longer to boot, even when using a prebuilt Jandex index,
apparently due to the use of Bytebuddy
> @Moritz Becker found the issue while trying to find out why our
Blaze-Persistence testsuite runs into CI timeouts with 5.4 but not with 5.3
> So AFAIK, the PojoEntityTuplizer builds the proxy class through
org.hibernate.proxy.pojo.bytebuddy.ByteBuddyProxyHelper#buildProxy which
takes significantly longer than the javassist implementation
I haven't tried it yet, but it seems to me that making the
byteBuddyState in
org.hibernate.bytecode.internal.bytebuddy.BytecodeProviderImpl static
might help. I'd guess this will help with the test execution time for
the Hibernate testsuite as well.
Any idea how to improve this @Rafael ?
Regards,
Christian
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev