Även om någon implementation kanske är dubbelt så snabb skulle jag oftast välja den som var lättast att förstå i de allra flesta fallen, någon annan kommer behöva öppna den filen om två år och antingen lägga till eller fixa något, då är det inte alls bra när det inte går att förstå enkelt vad som görs
Det går såklart att skriva kod som är båda snabb och går att förstå, men så länge man undviker de dummaste alternativen brukar mycket duga fint.
Dumma saker kan vara att parsea samma data många gånger, skicka allt som strängar som behöver läsas om många gånger, göra loopar i loopar, läsa samma data ur en databas många gånger vid samma anrop, … dessa går dock ofta enkelt att lösa om man tänker på vad man gör
Koden ska främst fungera, vara testad och gå att förstå, prestandan kommer oftast inte ens i tredje hand, och tiden den skrivs på är inte alls kritisk (alltså i måttet av rader/syntax per minut), utan måttet är hur lång tid man löser hela problemet på ett sätt som fungerar ihop med övrig kod utan att ställa till med andra problem och allt är testat och gör rätt