One of our concerns states that Gradle should be faster than Maven. We further detail this concern in the Gradle vs Maven section of our context view.
As mentioned throughout the AD, one of Gradle's desired quality properties is performance. We believe that our old AD did not properly address our stakeholders' performance related concerns. Therefore, we have decided to apply the Performance & Scalability perspective on the functional view and information view. We believe that scalability is not an issue. Consequently, we focus only on performance while applying the perspective.
Our development view is not relevant to performance. The context view should only enumerate the performance related mechanisms used by Gradle (in the Gradle vs Maven section). Therefore, we will not discuss changes to these views.
Following the corrections and additions brought about by the application of the performance perspective, our AD should give readers a detailed understanding of the architectural elements responsible for making Gradle builds faster than Maven.
We have added a section detailing the Gradle Daemon in our functional view. Our old AD introduced the Gradle Daemon as a functional component but did not attempt to explain why it is important or how it improves performance. The Gradle Daemon is a lingering background process which consumes memory and reuses the bootstrapping of previous builds to save time.
We believe that after reading the Gradle Daemon section, readers should be convinced that the Gradle Daemon is an architectural element responsible for a considerable performance increase and is significant enough to be modeled in our initialization component diagram.
The Gradle Daemon makes use of the Reuse Resources and Results architectural tactic by keeping resources (e.g. initialized libraries) in-memory rather than discarding them.
Our old information view did not address performance at all and focused mainly on flexibility. We've decided to add a build cache section to the information view.
The build cache enables some of Gradle's performance related features such as incremental builds and skipping the loading of some configuration objects during the configuration phase of Gradle's build lifecycle.
The build cache also clearly makes use of the Reuse Resources and Results architectural tactic by storing cacheable task's output results to the disk (or wherever the cache storage is located) for future reuse rather than discarding them.
Gradle makes use of the Partition and Parallelize architectural tactic by partitioning tasks according to their related project and allowing for the execution of tasks to be parallelized provided they are from different projects.
After applying the perspective to our other views, we realized that concurrency is important and provided explanations as to why a concurrency view is not included in our AD. To summarize, there is simply not enough architecturally significant information related to concurrency to warrant a concurrency view. Therefore, we decided to concisely explain how Gradle tackles parallelism while simultaneously explaining why we did not include a Concurrency View.