> Do you realise how insane it sounds to tell someone to profile their build config?
This is absolutely not insane.
I've saved over a minute per project per build simply by switching linkers (bfd -> gold IIRC?) in a large set of C++ projects. There were several projects - this easily saved 10 minutes per build when touching core libraries.
Considering my experience was that gradle builds were faster than corresponding ant builds (when not much has changed, in codebases with relatively small amounts of Java - e.g. I'm doing small iterations, which I care to optimize for), profiling what exactly is to blame seems worthwhile. I do it for 200ms hitches, why shouldn't I do it for multi-minute builds?
You want a build pipeline so fast that you don't even have a build step? So do I, but devs will still figure out how to add one which may take several minutes (e.g. unit tests.) - better to aim for a practical compromise that lets you iterate fast (hot reloadable scripts and data for example.)
> The fact that people need to do this is the problem.
To move this towards the realm of tautologies - performance problems are problems, yes. So solve them. But profile to ensure you're actually solving the right problem first.
Yes, ideally our build systems already have perfect caching - and could rely on filesystem events instead of directory scans for cache invalidation - and have blazing fast parsing steps, all resulting in subsecond build times.
On the other hand, it's insanely complicated to reach perfect caching for all buildable things - and there's only so much you can do if one of the buildable outputs is a large compressed file, for example (which is a common feature in pretty much every project I see, containing all the assets bundled and compressed in some form for better runtime performance.)
Dumb and simple tends to be more reliable, more understandable, and usually not too much worse. Although sometimes you'll be left profiling the edge cases and adding or fixing the caching involved.