Hi all. In Hibernate ORM we're having trouble with...
# community-supportc
Christian Beikov
08/29/2025, 1:59 PMHi all. In Hibernate ORM we're having trouble with compile times, because the incremental compilation is too coarse grained.
It looks like this was reported in the past, but unfortunately, there is no link to a GitHub issue where I could track the progress for that.
I tried to search for some keywords but couldn't find anything yet. Does anyone of you have an idea if this problem is tracked somewhere?
Christian Beikov
08/29/2025, 1:59 PMI debugged the SelectiveCompiler in Gradle a bit to understand how this works, and it seems to me, that this coarse grained-ness is sort of by design. The use of ClassSetAnalysis, which is used to determine dependent classes, assumes "the worst case" i.e. that a file changed fundamentally. I was wondering if the dependent classes calculation could happen after compilation of the changed source files. That way, a the dependent classes calculation could take into account if the changes were actually "visible" to dependent classes
Christian Beikov
08/29/2025, 2:00 PMI could imagine writing a diff utility for two class files that computes lists of changes that affect
ā¢ subclasses
ā¢ usages within the same package
ā¢ usages outside of the package but within same module
ā¢ usages outside of the package and outside of the module
based on that information, the amount of dependent classes could be reduced significantly in our case and probably also for many other users out there.
compilation for dependent classes would then be triggered separately. Not sure if you'd want to do separate compile transactions for the various passes or do all of that within one compile transaction with multiple compiler executions
a
Anze Sodja
08/29/2025, 2:09 PMI was wondering if the dependent classes calculation could happen after compilation of the changed source files.We calculate which classes we need to recompile after the file is changed. The problem is, that we don't analyse what in source file changed: did ABI change (e.g. method signature) or just implementation (e.g. method body)
v
Vampire
08/29/2025, 2:09 PMIt looks like this was reported in the past, but unfortunately, there is no link to a GitHub issue where I could track the progress for that.It should be fixed in 6.0 actually
Vampire
08/29/2025, 2:10 PMFound the related issue at https://github.com/gradle/gradle/issues/7401 and the PR that implemented it at github.com/gradle/gradle/pull/10419
c
Christian Beikov
08/29/2025, 2:10 PMThe problem is, that we don't analyse what in source file changed: did ABI change (e.g. method signature) or just implementation (e.g. method body)Yeah, that's exactly the problem we're running into
Christian Beikov
08/29/2025, 2:11 PMwe often change stuff in an ABI compatible manner, but then have to suffer excessive compilation times
š 1
a
Anze Sodja
08/29/2025, 2:14 PMNote that this is a problem only inside the same source set. We can detect such changes between projects though. So if you have a lot of classes in one project (or source set) then current solution is to split it in smaller projects to get better performance.
c
Christian Beikov
08/29/2025, 2:14 PMYeah, I understand that, but unfortunately, that's not possible
a
Anze Sodja
08/29/2025, 2:14 PMYeah, it's easier said than done...
c
Christian Beikov
08/29/2025, 2:15 PMso do you have a GitHub issue for this already?
a
Anze Sodja
08/29/2025, 2:15 PMHmmm, it should be somewhere
v
Vampire
08/29/2025, 2:17 PMThis one maybe https://github.com/gradle/gradle/issues/26337 ?
c
Christian Beikov
08/29/2025, 2:20 PMYeah, that looks like what I need š
Christian Beikov
08/29/2025, 2:20 PMthanks
Christian Beikov
08/29/2025, 2:22 PMassuming I wanted to work on this, what would be the process?
ā¤ļø 1
Christian Beikov
08/29/2025, 2:23 PMI guess we'd first have to discuss a design before I do anything and present you a PR
a
Anze Sodja
08/29/2025, 2:28 PMYes, it would be good to discuss it first. This is very complex part of the code, so it means also the team needs to spend some time reviewing changes too.
Which means it might happen they don't have time to work on it due to other priorities
c
Christian Beikov
08/29/2025, 2:31 PMI understand that. As an OSS developer, I am facing the same challenges in the Hibernate ORM community. Unfortunately, this issue is really destroying our productivity, so fixing it has a high priority for my team.
I'll start discussing ideas on the GitHub issue then, thanks
š 1
s
Sterling
08/29/2025, 2:46 PM
How big is the single source set? Do the changes propagate in a way that we end up just recompiling almost everything?
If you disabled incremental compilation, is it faster in the worst cases?
v
Vampire
08/29/2025, 2:48 PMIn the linked forum post it was 12K files of 15K files recompiled instead of one file recompiled as just a comment was added, but that is probably a really extreme example š
Vampire
08/29/2025, 2:48 PMAnd that was before the improvements in 6.0
s
Sterling
08/29/2025, 2:49 PM
sure, but I was wondering about Hibernate's specific example in case there was a short term fix to alleviate pain