3 ms·

Do you realise how insane it sounds to tell someone to profile their build config? The fact that people need to do this is the problem.

by shruubi 10y ago

MaulingMonkey 10y ago
> 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.
dlubarov 10y ago
I'm just suggesting that people are assigning blame in the wrong place. It's typically not Gradle's fault, but just that Gradle is being asked to perform a bunch of expensive (and often unnecessary) operations, like - The build might have dependencies with dynamic versions or changing modules (aka snapshots), meaning that Gradle periodically has to download the latest version. - The project might have proguard enabled for dev builds, which isn't really necessary. (As long as you smoke test release builds, which is a good idea anyway.) - The project might have dex merging enabled for dev builds, which isn't necessary unless you need to test something on a pre-ART device. - Engineers might be passing --clean or --refresh-dependencies, out of habit, when they're not needed. You could criticize Android's architecture for not being conducive to incremental builds, or you could criticize Android Studio for generating build files with some expensive functionality enabled. But none of this has much to do with Gradle.

Do you realise how insane it sounds to tell someone to profile their build config? The fact that people need to do this is the problem.

by shruubi 10y ago

Do you realise how insane it sounds to tell someone to profile their build config? The fact that people need to do this is the problem.

MaulingMonkey 10y ago

> 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.

dlubarov 10y ago

I'm just suggesting that people are assigning blame in the wrong place. It's typically not Gradle's fault, but just that Gradle is being asked to perform a bunch of expensive (and often unnecessary) operations, like - The build might have dependencies with dynamic versions or changing modules (aka snapshots), meaning that Gradle periodically has to download the latest version. - The project might have proguard enabled for dev builds, which isn't really necessary. (As long as you smoke test release builds, which is a good idea anyway.) - The project might have dex merging enabled for dev builds, which isn't necessary unless you need to test something on a pre-ART device. - Engineers might be passing --clean or --refresh-dependencies, out of habit, when they're not needed. You could criticize Android's architecture for not being conducive to incremental builds, or you could criticize Android Studio for generating build files with some expensive functionality enabled. But none of this has much to do with Gradle.