Er is iets mis in de wereld van softwareontwikkeling. De RAMpocalypse is ontstaan omdat hardware goedkoop is (of was) en programmeurs duur zijn. Dat betekent dat als een applicatie traag is of er een geheugenlek dreigt, er meer RAM-geheugen aan het softwareproduct wordt toegevoegd en er snellere CPU’s en meer opslag worden geïnstalleerd. Maar dit is niet bepaald een voorbeeld van efficiënte softwareapplicaties, toch? Wat moeten we hieraan doen?
Het RAMpocalypse-probleem wordt nu nog verergerd doordat hardware ook duur is, en dat zal waarschijnlijk tot volgend jaar zo blijven. Het maakt niet uit of een ontwikkelaar een videogame voor consoles, een streaming-app voor telefoons, een slimme koffiemachine, een infotainmentsysteem voor auto’s of een met Bluetooth verbonden yogamat bouwt. Het tekort aan halfgeleiders voor geheugen heeft roet in het eten gegooid bij de manier waarop elk bedrijf softwaregedefinieerde producten bouwt.
Maar een RAMpocalypse hoeft niet alleen maar kommer en kwel te zijn. Maurice Kalinowski, directeur productmanagement bij The Qt Group, denkt dat er manieren zijn om aan de dreigende gevolgen van deze ramp te ontsnappen.
“Als stijgende kosten de levenscyclus van hardware zodanig verlengen dat bedrijven langer vasthouden aan oude hardware, dan zou dat ironisch genoeg wel eens de aanleiding kunnen zijn voor ontwikkelaars om hun liefde voor software-optimalisatie nieuw leven in te blazen. Het is tijd dat software het zware werk gaat doen. Maar om dat te bereiken, zouden ontwikkelaars van desktopsoftware (en vooral mobiele apps) misschien eens moeten terugkijken naar de lean and mean-principes van embedded systemen”, aldus Kalinowski.
Het prototype-dilemma
Voor Kalinowski komt dit allemaal neer op wat hij het veelvoorkomende prototype-dilemma noemt, en dat gaat ongeveer als volgt.
Teams bouwen een proof-of-concept voor een cool, geweldig nieuw product… en misschien is het concept ook echt cool. Maar wat doen mensen van nature als ze op het punt staan iets cools te bouwen? Ze worden enthousiast! Dus grijpen ze natuurlijk naar de hoogwaardige programmeertaal die het gemakkelijkst is om mee te werken, maar die veel garbage collection vereist.
“Op dat moment is alles nog in orde. Een proof-of-concept is immers niet ontworpen om aan efficiëntienormen te voldoen, maar om te laten zien welke functies mogelijk zijn. De problemen ontstaan wanneer de opwinding omslaat in een overhaaste productiefase. Onder druk om een deadline voor de marktintroductie te halen, wordt de proof-of-concept-code (POC), die mogelijk opgeblazen en niet geoptimaliseerd is, gewoon verzonden. Soms is dat nu eenmaal hoe het loopt. Geen enkele softwareontwikkelingscyclus is perfect, en daarom bestaat het concept van Minimum Viable Product (MVP). Je neemt de beste beslissingen die je onder de gegeven omstandigheden kunt nemen om ervoor te zorgen dat het product wordt geleverd met de essentiële onderdelen”, aldus Kalinowski.
Het probleem hier is dat ontwikkelaars in de RAMpocalypse veel meer aandacht moeten besteden aan het geheugen als Key Performance Indicator (KPI). Als een softwarestack 3,5 GB RAM vereist, maar het hardwareteam alleen een module van 2 GB kan aanschaffen tegen een rendabele prijs, is er geen minimaal levensvatbaar product meer.
Shift left, dit keer op het gebied van prestaties
Maar we weten wel dat softwareontwikkelaars vaak spreken over ‘shift left’ in verband met het verplaatsen van testen naar een eerder stadium in de levenscyclus. Het argument van de Qt-man hier is dat we nu hetzelfde moeten doen voor prestaties.
Dat betekent dat prestaties en geheugengebruik niet langer een bijzaak zijn. Ze worden vanaf dag één kern-KPI’s. Mobiele en desktopontwikkelaars zijn echter begrijpelijkerwijs verwend geraakt door high-end apparaten. Ze ontwikkelen op de nieuwste iPhone of een RAM-zware Surface, terwijl de eindgebruiker misschien wel vastzit aan een veel ouder en beperkter apparaat, zoals een Pixel 6.
“Er zijn een paar dingen die we kunnen leren van de embedded wereld. Vraag het maar aan elke ontwikkelaar die aan embedded systemen heeft gewerkt en hij zal je waarschijnlijk vertellen dat het heel gebruikelijk is dat ze te horen krijgen dat ze een harde limiet hebben op hun resources. Ze krijgen misschien voorschriften als ‘Je mag maximaal 15% van de CPU gebruiken voor de UI’ en dat is een uiterst nuttige discipline voor met name desktop- en mobiele ontwikkelaars om toe te passen in hun workflow”, aldus Kalinowski.
Wacht niet, onderneem nu actie
Het advies is om niet te wachten tot gebruikers klagen dat een app te veel resources verbruikt terwijl Teams en Discord op de achtergrond draaien. Ontwikkelaars moeten duidelijke drempels instellen in hun ontwikkelingsinfrastructuur die voorkomen dat builds worden goedgekeurd als ze de resourcebarrières overschrijden.
“Je keuze van programmeertaal is misschien wel de belangrijkste factor in het resourceverbruik. Veel mensen werken graag met Python vanwege het gemak en de snelle iteratie die deze taal biedt. Is het de meest prestatiegerichte taal? Niet echt (hoewel er de afgelopen jaren vooruitgang is geboekt op dat gebied), dus als een ontwikkelaar werkt met een programmeertaal die veel garbage collection doet, heeft hij niet de controle die je nodig hebt over wat er gebeurt… en dat kan leiden tot een opeenstapeling van geheugengebruik. Aan de andere kant zien systeemtalen zoals Rust, C++ en Zig een heropleving omdat ze wel de gedetailleerde controle bieden die nodig is om te gedijen in een omgeving met beperkte resources”, legt Kalinowski uit.
Dat gezegd hebbende, merkt hij op dat het niet alleen om de programmeertaal gaat. Ontwikkelaars moeten in een vroeg stadium de technische schuld van de hele technologiestack aanpakken. Het is een beetje zoals het opruimen van een zolder, wat soms betekent dat je in een vroeg stadium moeilijke beslissingen moet nemen over wat je niet wilt bewaren. Voor een ontwikkelaar betekent dat dat hij elke bibliotheek die hij aan zijn project toevoegt, moet controleren op de impact ervan op het CPU- en geheugengebruik.
Ze moeten zich afvragen: “Heb ik deze hele bibliotheek echt nodig, of slechts delen ervan?”
De terugkeer van de optimalisatie-expert?
Kalinowski vindt dat er iets te zeggen valt voor het standpunt dat alle ontwikkelaars deze best practices zouden moeten toepassen. Maar als mensen vragen: “Is software-optimalisatie een verloren kunst?”, zegt hij dat het meest voor de hand liggende antwoord misschien wel is: veel bedrijven hebben eigenlijk geen domeinexpert op het gebied van software-optimalisatie. Om de RAMpocalypse te doorstaan, moet deze discipline een comeback maken. We hebben experts nodig die de ‘low-level’ kleine aspecten van het bouwen van software begrijpen, die samen grote besparingen opleveren.
Denk eens aan iets basaal als dit: hoe teken je een afbeelding? Er zijn zoveel manieren om dat te doen. Een beginner zou een afbeelding van 200×200 pixels als een onbelangrijke taak kunnen beschouwen en het bestand gewoon in het geheugen laden, maar een optimalisatie-expert weet dat er verschillende compressiemethoden zijn en manieren om de taak door te sturen naar de GPU om systeem-RAM te besparen.
Onthoud jullie geschiedenis, kinderen
“De geschiedenis geeft ons een sjabloon om mee te werken. Bedrijven als Nokia hadden ooit speciale teams die niets anders deden dan softwareprojecten doorlopen en code optimaliseren om deze sneller en slanker te laten werken. We gaan nu een tijdperk binnen waarin die gespecialiseerde vaardigheden opnieuw het verschil maken tussen een winstgevend product en een mislukt product”, aldus Kalinowski.
Naarmate we het AI-tijdperk ingaan, zal de verleiding groot zijn om snelle maar zware AI-gegenereerde code te gebruiken. Kalinowski van Qt Group concludeert dan ook dat, net als bij elke eerdere hardwaretekort, de RAMpocalypse vroeg of laat zal afnemen. Als dat gebeurt, moet de discipline van software-optimalisatie volgens hem blijven bestaan.