- Per Experiment wird belegt, warum „schnelle Build-Zeiten für Unternehmen wichtig sind“ und ob „leistungsstarke Cloud-Ressourcen tatsächlich teuer sind“
- Getestet wurden Build-Zeiten auf GitHub Large Runnern mit 2 bis 64 Kernen (Fedora-Linux-Kernel)
Die Kosten langsamer Build-Zeiten für Unternehmen
- Bei einem durchschnittlichen Entwicklergehalt von $150K entspricht das $75 pro Stunde
- Wenn ein Build 1 Stunde dauert und der Entwickler in dieser Zeit nichts anderes tut, entstehen dem Unternehmen schlicht $75 Kosten
- Ergebnisse (Fedora 36)
- Kerne (Preis pro Minute) - gesamte Build-Zeit - Kosten pro Build - Entwicklerkosten (1 Person)
- 2 Kerne($0.008/Min.) - 310 Min. - $2.48 - $389.98
- 8 Kerne($0.0032/Min.) - 92 Min. - $2.94 - $117.94
- 16 Kerne($0.064/Min.) - 55 Min. - $3.52 - $72.27
- 32 Kerne($0.128/Min.) - 35 Min. - $4.48 - $48.23
- 64 Kerne($0.256/Min.) - 27 Min. - $6.91 - $40.66
- Fazit: Je mehr Entwickler beteiligt sind, desto effizienter ist es, Geld für leistungsfähigere Hardware auszugeben
Die Kosten von Kontextwechseln für Unternehmen
- Wenn man annimmt, dass Entwickler während des laufenden Builds andere Aufgaben erledigen
- Dann entstehen auch durch Kontextwechsel Kosten. Studien zufolge dauert das im Schnitt etwa 23 Minuten
- Meiner persönlichen Erfahrung nach dauert der Wechsel von einer konzentrierten Aufgabe zu einer anderen eher eine Stunde
- Ergebnisse (berechnet mit etwa 30 bis 15 Minuten)
- Kerne - Build-Zeit - Kosten pro Build - anteilige Entwicklerkosten (1 Person, 30 Min.) - anteilige Entwicklerkosten (1 Person, 15 Min.)
- 2 Kerne - 310 - $2.48 - $39.98 - $21.23
- 16 Kerne - 55 - $3.52 - $41.02 - $22.23
- 64 Kerne - 27 - $6.91 - $44.41 - $25.66
- Unter der Annahme von Entwicklerkosten von $75 pro Stunde ist es deutlich effizienter, mehr Geld für Computer auszugeben
- Selbst der teuerste 64-Kern-Runner kostet nur ein Fünftel des Stundensatzes eines einzelnen Entwicklers
Fazit
- Für bessere Hardware zu bezahlen ist in der Praxis günstiger und besser für Entwickler, weil es Unterbrechungen reduziert
- Im obigen Experiment spart es bei einem einzelnen Entwickler $40 und bei einem 5-köpfigen Team über $200, wenn man für die Build-Zeit zusätzlich $4 bis $5 ausgibt, und zugleich auch die Stunde für Task-Switching
- Natürlich kann es sich in großen Unternehmen summieren, pro Build $4 bis $5 auszugeben, aber die verlorene Produktivität summiert sich ebenfalls
- Geld für bessere CPU-Leistung auszugeben, zahlt sich mit der Zeit aus.
Natürlich werden Entwickler es Ihnen danken
9 Kommentare
Zustimmung
https://xkcd.com/303/
Offenbar ist es ein weltweites Phänomen, dass man während der Build-Zeit plötzlich nichts Sinnvolles mehr zu tun hat.
Wow, genau das hat mich wirklich interessiert. Im GitHub-Blog gibt es offenbar mehr zu entdecken, als ich gedacht hatte. Es beruhigt mich, dass wohl nicht nur ich beim Builden nebenbei etwas anderes mache oder ständig daran denken muss (?.
Zugegeben. Ich bevorzuge Desktop-Rechner statt Plus-Laptops.
Dem kann ich zustimmen. Ich bin Deep-Learning-Forscher und nutze mehrere Geräte gleichzeitig.
Da ich im Alltag häufig Experimente laufen lasse, kommt es oft vor, dass ich alle Ressourcen verwende.
Dabei entstehen zwischendurch immer wieder Leerlaufzeiten.
Und während eines Experiments andere Aufgaben zu erledigen, lenkt einen unterschwellig auch ab.
Liegt das Durchschnittsgehalt bei 150.000 $?
Ich hatte gelegentlich frustrierende Momente wegen der Leistungsgrenzen meines PCs oder Servers, und ich hatte eindeutig das Gefühl, dass meine Produktivität darunter litt im Vergleich zu Zeiten, in denen alles flott lief.
Aber das stimmt schon.
Früher habe ich an Projekten gearbeitet, bei denen ein Build jedes Mal eine Stunde gedauert hat ...
Wenn man den Build anstößt, macht man bis zum Ende immer irgendetwas anderes, haha.
Während der Build läuft, fängt der PC manchmal auch an zu ruckeln ...
Und selbst wenn man wegen der Arbeit etwas anderes macht, schaut man doch immer wieder mal nach dem Build-Fortschritt, sodass man sich nicht richtig konzentrieren kann.
Zwar ist es letztlich ein werblicher Artikel für GitHub Large Runners, der dazu auffordert, gute Build-Instanzen zu verwenden, aber …
Punkt #9 des The Joel Test – „Kauft euren Entwicklern die teuerste Ausrüstung, die ihr euch leisten könnt“ – gilt im Cloud-Zeitalter genauso.