This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-02-07
Channels
- # aleph (4)
- # announcements (9)
- # babashka (44)
- # beginners (6)
- # cider (8)
- # clj-kondo (5)
- # clojars (10)
- # clojure (10)
- # clojure-berlin (1)
- # clojure-dev (9)
- # clojure-europe (20)
- # clojure-gamedev (1)
- # clojure-miami (2)
- # clojure-nl (1)
- # clojure-norway (21)
- # clojure-uk (5)
- # clojurescript (12)
- # conjure (1)
- # cursive (19)
- # data-science (2)
- # datahike (10)
- # etaoin (5)
- # events (3)
- # fulcro (14)
- # gratitude (2)
- # honeysql (8)
- # humbleui (1)
- # hyperfiddle (60)
- # introduce-yourself (7)
- # jobs-discuss (27)
- # juxt (2)
- # kaocha (7)
- # lsp (23)
- # malli (9)
- # missionary (2)
- # off-topic (48)
- # pathom (24)
- # releases (1)
- # shadow-cljs (256)
- # sql (46)
- # xtdb (19)
En liten refleksjon: Kode som er hardt tuna for ytelse ender lett opp med å bli veldig "lukka". Det er mye ytelse å hente i å fjerne usikkerhet og potensiale, så det å komme tilbake å legge til flere features i kode som allerede er tuna hardt for performance er... Mindre rett frem enn man kanskje skulle ønske seg 😅
ville det hatt noen verdi å ta vare på koden før den ble tuna? Så kunne man gjort endringer i API-er i den koden, og så heller gjort tuninga på nytt. Kanskje via en slags dokumentasjon på hvordan koden kan tunes?
eventuelt “deoptimalisere” koden for å gjøre den hyggeligere å jobbe med, før man gjør endringer, og så “make it fast” en gang til?
Det er en kostbar øvelse (i tid) å tune ting, så jeg tror det er lurt å gjøre det så sent som mulig. Du kan selvfølgelig gjøre som du foreslår, men det er ikke mange endringene som skal til før koden din er på et annet nok sted til at du må tenke ut en del tuning på nytt
Den koden som er tuna har ikke så mange "åpne vinduer" som jeg er vant til. Ting er låst for å fjerne tvil - ingen valgfrie argumenter, få hjelpefunksjoner osv osv. Ting er inline og satt i stein sånn det er.
Det går altså, det er bare mindre rett frem enn jeg er vant med. Vanligvis optimaliserer jeg koden først og fremst for leseren.