Forleden byggede jeg mit eget CRM i en tekstfil. I går spurgte jeg mig selv: kan den køre hurtigere? En af kommandoerne — den, der kobler kontakter sammen med min aktivitetslog — tog godt et sekund. Ikke katastrofalt, men nok til at irritere.
Svaret blev ja: fra 1033 millisekunder til 93 — elleve gange hurtigere. Men det interessante er ikke tallet. Det er, hvordan man finder derhen, og hvorfor det overhovedet var muligt.
Den vigtigste regel: mål, før du gætter
Den største fælde i optimering er at gætte på, hvor problemet ligger, og så bruge en dag på at gøre den forkerte ting hurtig. Så jeg startede med at måle. Det viste sig, at ud af de 1033 millisekunder gik næsten 1000 i én enkelt funktion. Resten af programmet var allerede hurtigt nok.
Det er næsten altid sådan. Langsomhed er sjældent spredt jævnt ud — den sidder ét sted og venter på at blive fundet. Måler man først, optimerer man det rigtige. Gætter man, optimerer man ofte noget, der i forvejen var ligegyldigt.
Hvad der var galt: en skjult kvadratisk fælde
Funktionen byggede en stor opslagstabel ved at tilføje én post ad gangen til en voksende datastruktur. Problemet: i det værktøj, jeg brugte, kan den slags struktur ikke ændres — hver tilføjelse laver i stedet en hel kopi. Med nogle tusinde kontakter betød det millioner af unødvendige kopier. Arbejdet voksede kvadratisk: dobbelt så mange kontakter, fire gange så langsomt.
Løsningen var todelt. Først erstattede jeg den voksende kopiering med en rigtig sammenkoblings-operation, som værktøjet løser internt på halvandet millisekund. Dernæst byggede jeg selve tabellen i ét hug i stedet for kontakt for kontakt. Tilsammen faldt tiden fra et sekund til under et tiendedels.
Pointen, der gælder ud over kode
Tre ting er værd at tage med, også hvis man aldrig selv skriver en linje kode:
Det havde intet med AI eller mere hardware at gøre. Jeg købte ikke en hurtigere computer og tilføjede ikke en model. Gevinsten kom udelukkende af at forstå, hvordan værktøjet håndterer data. De kedelige fundamenter — ikke det nye og blanke — er næsten altid der, den rigtige ydelse ligger. Det er let at glemme i en tid, hvor svaret på alt skal være "smid AI på det".
Mål, før du handler — også i forretningen. Princippet er det samme, uanset om du optimerer kode eller en arbejdsgang: find ud af, hvor tiden faktisk går, før du laver om. De fleste flaskehalse er ikke der, hvor man tror. Den dyreste fejl er at forbedre det, der allerede virkede.
Og så det afgørende: jeg kunne overhovedet gøre det, fordi jeg ejer koden. Var mit CRM en cloud-løsning, der var langsom, kunne jeg vente, sende en supportbillet og håbe. Fordi det er mit, kunne jeg måle, finde flaskehalsen og rette den på en eftermiddag. Det er den anden halvdel af pointen om at eje frem for at leje sine data: ejer du systemet, kan du ikke bare flytte dine data — du kan også forbedre det, når det driller, i stedet for at stå i kø.
Til sidst
Elleve gange hurtigere lyder dramatisk, men det krævede hverken talent eller nyt isenkram. Det krævede at måle i stedet for at gætte, og at forstå sit værktøj godt nok til at se, hvad der i virkeligheden foregik.
For en virksomhed er det en undervurderet form for kompetence. Ikke "vi har det nyeste" — men "vi forstår, hvad vi har, og kan forbedre det selv". Det er forskellen på at eje sit værktøj og at være afhængig af, at en andens roadmap engang når frem til dit problem.