Een ontwikkelaar van Google Chrome was het beu dat een nieuwe build van de webbrowser zo lang duurde na een verandering in slechts één broncodebestand. Uit frustratie ontwikkelde hij daarom een nieuw build-systeem, Ninja. De build-performance van software is altijd een combinatie van heel wat factoren, schrijft Google-ontwikkelaar Evan Martin in een blogpost over zijn nieuwe build-systeem.

Stappen optimaliseren

Het build-systeem zelf (traditioneel GNU make met Makefiles) moet berekenen wat er met welke bestanden moet gebeuren, de compiler moet de bronbestanden compileren en de linker heeft ook tijd nodig om de objectbestanden te linken tot het uiteindelijke uitvoerbare programma. Google had elk van deze stappen al wel sterk geoptimaliseerd. Daardoor duurde een incrementele build van Google Chrome na wijzigingen in enkele bestanden nog maar 10 tot 20 seconden.

Martin was echter nog altijd niet tevreden. Tussen het moment dat hij het commando make intypte en de eerste compilatiestap werd gezet, zat zeker nog 10 seconden. Hij ontdekte dat Make heel wat overbodige zaken controleert. Bovendien zijn heel wat taken (zoals een bestand opnieuw compileren wanneer de compilatieflags gewijzigd zijn) met make alleen mogelijk door slimme maar inefficiënte hacks.

Secondenwerk

Daarom schreef Martin een nieuw, heel eenvoudig en heel efficiënt build-systeem: Ninja. Het resultaat: de Chrome-build begint nu al na één seconde te compileren. En een incrementele build van Chrome na het wijzigen van één bestand duurt met Ninja nu nog maar zes seconden.

Meer informatie over de werking van Ninja en hoe je ermee aan de slag gaat is te vinden in de manual. Interessant is dat Ninja voor elk gebouwd bestand een log bijhoudt met het gebruikte commando. Dankzij deze log kan Ninja bijvoorbeeld weten wanneer een bestaand objectbestand op basis van een C-bestand gecompileerd was met andere C-parameters dan de huidige. Het weet dan dat het dit bestand dus opnieuw moet compileren. Ninja biedt ook een tool om de dependency graph in een webbrowser te bekijken of te exporteren naar het Graphviz-formaat.

Vooral voor grote projecten

Ninja is nu nog het speeltje van een ontwikkelaar die geobsedeerd is door build performance, wat vooral bij grotere projecten belangrijk is. Om een idee te geven: de broncode van Google Chrome bestaat uit zo'n 30.000 bestanden. Als je dan dankzij Ninja de build sneller kan laten verlopen, win je al vlug enkele seconden, wat heel handig is voor de ontwikkelaars. Google is in juli vorig jaar overgestapt op een snellere ontwikkeling van Chrome: elke zes weken een nieuwe versie.

Voor kleinere projecten echter, met tientallen tot honderden bestanden, zal de snelheidswinst eerder beperkt zijn tot een fractie van een seconde. Dat is in de praktijk niet merkbaar voor ontwikkelaars. Make en andere build-systemen zullen dus niet zo snel aan de kant gezet worden, ook omdat ze heel wat meer geavanceerde mogelijkheden bieden dan Ninja. Voor projecten van de omvang van Google Chrome kan Ninja echter een interessant alternatief zijn om in het oog te houden.