tools-build 2025-09-12

The tools build uber task can be a little slow - looking at the code, it’s highly sequential, handling conflicts one by one. However, I wonder if there might be some way to pre-process and find conflicts ahead of time, allowing non-conflicting files to be processed in parallel? Is this even a good idea?

the most common slowdown i've seen is having a security app on your machine that scans files as they're written. for me, building with that app enabled takes minimum 30s. without it, like 5s

sheer shock and awe: you have 110k files in your jar?

we do! it’s a big project

think it’s not that unusual for large clj projects?

I’ve trimmed almost all the fat I can from this too

i guess i'll check my old prod app. should build that every once and awhile anyways

but okay to start: maybe just copy the entire uberjar namespace into your project and lets tweak from there

then once you are done tweaking and profiling see if there is anything worth merging back up

I stared a fork already - but it had some odd bugs, and was pulling it in as a git dep https://github.com/dazld/tools.build/tree/parallel-uber

instead of forking the library itself i'd just copy that one file and change the namespace to your.company.tools.build.tasks.uber

this is also pretty easy

but yep, could do that too

since i'd say 50/50 the conclusion is going to be "yeah you get your own special snowflake"

tbh - even when the parallel build was up, even if buggy, it wasn’t that much faster

but I do think there’s opportunity here

fortunately, that’s not an issue for us on CI or locally (afaik) - we have some 110k files in our JAR, so it’s not surprising it takes some time to build I suppose.

> jar tf uber.jar | wc -l 
109901
but - I can see that only about ~5k of those paths were conflicting, so, forcing the possibly slower sequential build for over 95% of the files to package feels like there might be an opportunity to speed it up a little.

it all adds up!