Fork me on GitHub
#clojure-norway
<
2024-01-09
>
cjohansen06:01:02

Artig 😊

slipset07:01:35

Hadde vÊrt morsomt Ä spÞrre theller om hvorfor ting mÄ vÊre sÄ raskt, annet enn at han er litt syklig opptatt av hastighet.

👍 1
leifericf08:01:43

Ja, og pÄ hvilken bekostning. Typ, gÄr Þkt hastighet pÄ bekostning av noe annet, og er det verdt det.

cjohansen08:01:02

@slipset det virker for meg som om ClojureVerse er et Ă„pent forum, et hvor du sĂ„gar har en konto 😄 Bare Ă„ spĂžrre 😊

slipset08:01:22

Da har jeg spurt


👍 1
augustl09:01:26

angÄende macroer vs data, Pete Hunt (en av de som lagde fÞrste versjon av React) sa at ytelse var grunnen til at rendring skjedde med funksjonskall, ikke data

augustl09:01:04

JSX compiler vel til funksjonskall og, ikke data (`React.createElement("article", {}, React.createElement("h1", {}, "Foo..."))` )

cjohansen09:01:00

Jeg er fullstendig klar over at det koster mer Ä rendre fra data enn fra makroer. Derfor jeg har jobbet sÄ hardt for Ä fÄ rendring fra data til Ä bli raskt nok.

🙌 1
augustl09:01:40

tipper det var mere sant pÄ mobiler i 2013 enn i dag og, hvor RAM var mangelfult og treigt

augustl09:01:47

hele designet til UITableView pÄ tidlig iOS var vel strukturert rundt nettopp det, altsÄ at RAM var treigt, sÄ man driver og gjenbruker views og greier og oppdaterer dem, i stedet for Ä lage nye, siden allokering av 10-20 views i sekundet var mere enn en iPhone klarte i 2008

augustl09:01:22


.og i Clojure-land kan man jo noksÄ enkelt hoppe over hele render-funksjonen med shouldComponentUpdate-aktige greier og

augustl09:01:23

har replicant det steget, forresten? AltsÄ tilstand i render-treet for Ä sammenligne input fra forrige og innevÊrende render?

augustl09:01:48

kult, den differ altsÄ outputen av funksjonene, ikke inputen?

cjohansen09:01:17

replicant er bare et rendering-bibliotek for hiccup, den legger seg ikke opp i hvordan du lager hiccup

cjohansen09:01:00

Den tar vare pÄ hiccup mellom hver render og bruker det til Ä avbryte rendering nÄr ting ikke har endret seg

❀ 1
augustl09:01:14

hah, det er jo ganske rĂ„tt. Hvor simpelt klarer man Ă„ lage det liksom, og likevel rendre kjapt som bare det 😄

augustl09:01:39

der er det jo Ă„pning for en spennende optimalisering og. I det laget som genererer hiccup kan man se pĂ„ props (input) og gjĂžre tilsvarende “bare oppdater det som er nĂždvendig” ved Ă„ generere update-in/assoc-in, og dra nytte av clojure sine persistente datastrukturer mot for Ă„ bare lage ny hiccup fra bunnen av hver render (hilsen August “Premature Optimization” Lilleaas)

Zeniten09:01:46

AKA August "The Root of All Evil" Lilleaas 😄 Morn!

😂 4
leifericf11:01:09

Det sitatet fortjener Ä vÊre pÄ en T-skjorte eller kaffekopp i @U0MKRS1FX sin besittelse.

augustl12:01:22

jeg har en lang historie med flotte utmerkelser i mitt navn :hugging_face:

😂 1
cjohansen09:01:56

Jeg hadde opprinnelig tenkt til Ä tilby en komponent som en funksjon med auto-memoize, men fikk ikke nok ut av det i benchmarks, sÄ jeg droppa det

cjohansen09:01:20

Det er ihvertfall gjeldende teori, vi fÄr se om den stÄr seg

augustl09:01:33

“komponenter er eneste gyldige abstraksjon for Ă„ generere hiccup til rendring” - hodet mitt for 5 minutter siden

cjohansen09:01:15

Hvis du har flere argumenter for komponenter sĂ„ kom med dem, sĂ„ vurderer jeg om det er noe jeg ikke har tenkt pĂ„, eller om jeg skal legge til noe i Readme-en 😄

augustl09:01:11

mÄtte kanskje vÊre noe devtools-greier, men det kan man vel ogsÄ fÄ til uten komponenter pÄ et eller annet vis via en macro som putter noe replicant-metadata i hiccupen eller noe sÄnt. AltsÄ kunne se i Chrome at denne

-en mapper til my-component-foo

cjohansen09:01:32

Ja, det har jeg vĂŠrt innom

cjohansen09:01:49

Det er det beste argumentet for noe rammeverks-spesifikt jeg har kommet pÄ sÄ langt

cjohansen09:01:21

Som du sier blir lÞsningen enten metadata eller et "attributt" - sÄ fÄr vi se om det har noe for seg Ä lage en makro bare for Ä legge den pÄ

✅ 1
augustl09:01:16

nesten sĂ„ man kunne distribuert det som en egen pakke/dependency eller noe i sĂ„ fall, hjernen min hadde ikke “grokka” at replicant ikke har komponenter om det var med en defcomponent 😄

cjohansen09:01:32

Jeg lekte meg med dette i gÄr. Det var basert pÄ fÞlgende hiccup:

(defn app [{:keys [square?]}]
  [:div {:replicant/component {:name "replicant.dev/app"}}
   [:h1 "Watch it go!"]
   (when square?
     [:div {:class "some classes"
            :style {:transition "width 0.5s, height 200ms"
                    :width 100
                    :height 200
                    :background "red"
                    :overflow "hidden"}
            :replicant/mounting {:style {:width 0 :height 0}}
            :replicant/unmounting {:style {:width 0 :height 0}}}
      "Colored square"])
   [:p {:replicant/key "p"} (if square? "Square!" "It's gone!")]
   ])

đŸ˜» 1
augustl09:01:20

klarer ikke Ä komme pÄ noe annet tilfelle hvor man mÄ ha components annet enn hvis man skal ha tilstand i render-treet

augustl09:01:00

og det kan man jo ha med replicant og, strengt tatt, via :replicant/node ? Aka fiske ut DOM-elementet og gjĂžre hva man skulle Ăžnske utenifra, som Ă„ rendre en tredjeparts wysiwyg-editor eller hva det skulle vĂŠre

cjohansen09:01:12

Du har life-cycle hooks, hvor du fÄr noden og kan gjÞre hva du vil (pÄ egen risiko)

teodorlu10:01:39

synes det er spennende Ä se hvordan du jobber med ytelse og benchmarking, @christian767. Ikke skrive masse kode med masse optimaliseringer, men gÄ stÞdig fram steg etter steg og ha is i magen pÄ hva optimaliseringen vil bety. Feks pÄ funksjoner/data/makroer. SpÞrre seg selv tydelig hvor langt man kan komme med data fÞr man i hui og hast lager et annet grensesnitt.

💯 2
cjohansen11:01:58

Takk for det 😊 Skal sies at jeg ikke startet dette prosjektet med ytelse som primĂŠrmĂ„l. PrimĂŠrmĂ„let er programmeringsmodellen, og sĂ„ mĂ„ det liksom yte godt nok til Ă„ kunne tilbys som et godt valg blant alternativene. At jeg gĂ„r sĂ„ppass forsiktig frem handler mest om at jeg har lite erfaring med benchmarking og ytelsestuning. Har lĂŠrt masse av @slipset sine bidrag og analytiske gjennomgang 😊

👍 2
💜 1
gratitude 1
teodorlu11:01:54

At ytelse ikke er primÊrmÄlet - men heller Ä lage en god lÞsning til et problem - vil jeg si er et sunnhetstegn!

👍 3
cjohansen11:01:51

👀 1
👍 1
cjohansen11:01:18

Interessant. shadow-grove er ikke i en heeelt annen liga. Burde vĂŠre mulig Ă„ tyne avstanden littegrann 😅

👍 2
augustl11:01:37

TIL: volatiles (via (volatile! ..)) , til nÄr du trenger en muterbar peker, men ikke trenger alle featurene til atomer

Ivar Refsdal09:01:52

https://clojuredocs.org/clojure.core/with-local-vars finst ogsÄ, om ein er sikker pÄ at var-en kun vert brukt frÄ same trÄd. Vil tru den er raskare enn volatile! (men eg har ikkje testa)

đŸ˜Č 2
augustl10:01:25

oi, den var skikkelig heftig! En ekstra intens versjon av transients, og “if a tree falls in the wood and nobody is there to hear it, did it make a sound? If a function mutates some local state and returns an immutable value, is it pure?”

thinking-face 1
augustl12:01:36

bruker dere benchmarks og flame graphs og sÄnt aktivt for Ä finne ut hva som gÄr treigt? Kanskje for sent nÄ, men hadde vÊrt en kul screencast-serie Ä se hvordan dere gikk frem for Ä optimalisere slike ting

cjohansen13:01:55

Bruker det verktÞyet som er screenshotta over som "fasit", har skrevet om det i readme-en. Ellers har jeg brukt profileren i Chrome en del for Ä finne ut av hvor det gÄr mest tid, og jeg har ogsÄ gjort noe manuell instrumentering av kode (atom + tap eller lignende) for Ä fÄ oversikt over hvilke funksjoner som kalles hyppigst. De stÞrste seierne har kommet av Ä fÄ ned antall kall til ymse funksjoner. @slipset har ogsÄ lagt til en flamegraph-sak som han har brukt til Ä finne hotspots. Jeg har kikka litt pÄ den, men er ikke "fluent" med den enda.

augustl14:01:59

spurte jetbrains sin AI
 ymmv

cjohansen14:01:14

Punkt 5 kan vĂŠre noe Ă„ forfĂžlge

cjohansen14:01:43

Reflection er ikke et problem i JS. Sikkert lurt Ä type-hinte uansett da, sÄ det er raskt pÄ JVM-en ogsÄ.

cjohansen14:01:31

2. Denne er veldig fin-tunet - koden kommer fra hiccup. .indexOf/.substring er dramatisk raskere enn den tidligere varianten med split (og, opprinnelig, regexp 😼 )

cjohansen14:01:31

Punkt 4 skal hÄndteres av algoritmen som kaller pÄ denne. Jeg tror det skal vÊre mulig Ä kutte ned antall kall hit ytterligere.

slipset19:01:11

Glemte Ă„ nevne dette igĂ„r, jeg har blitt (midlertidig) frontend arkitekt i Ardoq 🙂

😼 1
🎉 3
cjohansen19:01:46

Oooh! Gratulerer 😄

cjohansen20:01:31

Hva innebérer det, og hvor lenge er det midlertidig? 🙂

slipset21:01:21

Midlertidig til vi finner en skikkelig en. SÄnn som jeg definerer rollen er det litt Ä vÊre ansvarlig for at den arkitekturen og de kodekonvensjonene vi har bestemt blir fulgt, samt sikkert noe videreutvikling av disse. Det handler vel ogsÄ om Ä finne ut/iverksette strategier for Ä bli kvitt backbone.

slipset21:01:43

Egentlig ikke noe revolusjonerende, men vi trenger noen som bryr seg om frontend kodebasen.

đŸ’Ș 1
❀ 1
Ivar Refsdal09:01:52

https://clojuredocs.org/clojure.core/with-local-vars finst ogsÄ, om ein er sikker pÄ at var-en kun vert brukt frÄ same trÄd. Vil tru den er raskare enn volatile! (men eg har ikkje testa)

đŸ˜Č 2