https://gradle.com/ logo
Join Slack
Powered by
Can I store a configuration in a `BuildService` ? ...
# community-support
m
Can I store a configuration in a 
BuildService
? I'm guessing nothing prevents it? But I'm not sure I've seen this pattern before so I thought I'd ask
Actually, can a configuration be shared between 2 projects? 🤔
That sounds dangerous. But at the same time there is nothing specific about my project in my configuration. Might as well save resolving it multiple times?
v
Puh, good question. Depends probably on how you use it maybe. Also, maybe it would make more sense to have a 
ConfigurableFileCollection
in the build service to which you add the configuration? 🤷‍♂️
m
Part of it was trying to save the number of 
Configuration
objects created, I had a discussion not so long ago where people mentioned 
Configuration
was quite expensive
I guess if it's resolved to a 
FileCollection
already, I could just skip creating the configuration 🤔
I think that'd work, thanks!
Mmm although it might not be that easy if I want to resolve at execution time because I can't really create configurations at execution time because my 
project
references are long gone...
Oh well, I'll just skip the optimization, problem for later
v
It's new to me that configurations are expensive, I never refrained from creating new ones where needed. Even if multiple projects have the same, resolution and especially artifacts should anyway be cached in the Gradle cache. A 
Configuration
actually is a 
FileCollection
also. If you for example try to have a 
Configuration
property in a task, configuration cache will complain as 
Configuration
is not supported. But by simply having an explicit type of the property to be 
FileCollection
, the configuration cache treats the 
Configuration
as 
FileCollection
and properly handles it. With configuration cache, the dependency resolution is anyway done latest at the time the CC entry is written and not actually at execution time. In the CC entry there is then only the result of the resolution and it requires the files in the Gradle cache to be present.
m
Got curious and did this:
Copy code
measureTime {
  repeat(1_000_000) {
    configurations.create("test$it")
  }
}.let {
  println("took $it")
}
It takes ~2s to create 1M configurations on my MacBook and uses ~3GB of heap So probably the memory is the issue there
This was my message back then
The issue was with very large builds (1000 projects each one having 1000 configurations is not completely impossible)
v
o_O I hope you found a memory leak 😄
m
Well, I didn't investigate too long but I think this adds up. A configuration being 3kB sounds plausible
v
Hm, well, then maybe such big builds just need that much heap 🤷‍♂️
m
I think this was the reasoning behind splitting between 
resolvable
vs 
consumable
configurations so that each one would use less memory but that effort isn't completely over the finish line yet
Open in Slack
PreviousNext
Powered by