That’s just my opinion though, I will also show how to run benchmarks on a continuous basis as well. It can also be determined at the time of code review whether a changeset can affect build speeds. Ideally, you would want to check build times when you have introduced a new library, or changed some Gradle configuration or version, or did some refactor effort for modularisation, etc. I specifically chose to make workflow on-demand and not continuous because it is unnecessary and suboptimal from a costing and carbon perspective. In this article, I will explain how I built an automated, on-demand build benchmarking workflow using Github Actions. That’s where gradle-profiler and Github Actions come to our rescue. Benchmarking builds after every change can be a tedious and time-consuming task, again, especially for larger codebases.
However, one also needs to measure the efficacy of those optimizations. There are many build performance optimizations techniques and tutorials are available out there that one can apply to keep build speeds in check. Since Kotlin is known to have larger build times then Java it becomes even more important keep a tab on those build times. Nowadays Kotlin is the preferred choice of development language for many developers(including myself). It specifically becomes a nuisance when your codebase is large. Slow build speeds are not unfamiliar to us Android Developers.
0 kommentar(er)
