This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-01-09
Channels
- # announcements (9)
- # babashka (14)
- # beginners (27)
- # biff (4)
- # calva (3)
- # cider (14)
- # clojure (36)
- # clojure-austin (1)
- # clojure-europe (43)
- # clojure-japan (4)
- # clojure-nl (2)
- # clojure-norway (59)
- # clojure-uk (6)
- # clojurescript (13)
- # conjure (2)
- # data-science (3)
- # datomic (3)
- # deps-new (40)
- # hyperfiddle (72)
- # jobs (2)
- # lsp (8)
- # malli (10)
- # missionary (3)
- # off-topic (22)
- # overtone (3)
- # reagent (12)
- # releases (1)
- # squint (1)
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.
Ja, og pÄ hvilken bekostning. Typ, gÄr Þkt hastighet pÄ bekostning av noe annet, og er det verdt det.
@slipset det virker for meg som om ClojureVerse er et Ă„pent forum, et hvor du sĂ„gar har en konto đ Bare Ă„ spĂžrre đ
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
JSX compiler vel til funksjonskall og, ikke data (`React.createElement("article", {}, React.createElement("h1", {}, "Foo..."))` )
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.
tipper det var mere sant pÄ mobiler i 2013 enn i dag og, hvor RAM var mangelfult og treigt
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
âŠ.og i Clojure-land kan man jo noksĂ„ enkelt hoppe over hele render-funksjonen med shouldComponentUpdate-aktige greier og
har replicant det steget, forresten? AltsÄ tilstand i render-treet for Ä sammenligne input fra forrige og innevÊrende render?
replicant er bare et rendering-bibliotek for hiccup, den legger seg ikke opp i hvordan du lager hiccup
Den tar vare pÄ hiccup mellom hver render og bruker det til Ä avbryte rendering nÄr ting ikke har endret seg
hah, det er jo ganske rĂ„tt. Hvor simpelt klarer man Ă„ lage det liksom, og likevel rendre kjapt som bare det đ
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)
Det sitatet fortjener Ä vÊre pÄ en T-skjorte eller kaffekopp i @U0MKRS1FX sin besittelse.
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
âkomponenter er eneste gyldige abstraksjon for Ă„ generere hiccup til rendringâ - hodet mitt for 5 minutter siden
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 đ
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 Det er det beste argumentet for noe rammeverks-spesifikt jeg har kommet pĂ„ sĂ„ langt 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Ă„ 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 đ Jeg lekte meg med dette i gĂ„r. Det var basert pĂ„ fĂžlgende hiccup:
klarer ikke Ă„ komme pĂ„ noe annet tilfelle hvor man mĂ„ ha components annet enn hvis man skal ha tilstand i render-treet og det kan man jo ha med replicant og, strengt tatt, via Du har life-cycle hooks, hvor du fĂ„r noden og kan gjĂžre hva du vil (pĂ„ egen risiko) 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. 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 đ At ytelse ikke er primĂŠrmĂ„let - men heller Ă„ lage en god lĂžsning til et problem - vil jeg si er et sunnhetstegn! Interessant. shadow-grove er ikke i en heeelt annen liga. Burde vĂŠre mulig Ă„ tyne avstanden littegrann đ
TIL: volatiles (via 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 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?â 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 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. Reflection er ikke et problem i JS. Sikkert lurt Ă„ type-hinte uansett da, sĂ„ det er raskt pĂ„ JVM-en ogsĂ„. 2. Denne er veldig fin-tunet - koden kommer fra hiccup. .indexOf/.substring er dramatisk raskere enn den tidligere varianten med split (og, opprinnelig, regexp đź ) Punkt 4 skal hĂ„ndteres av algoritmen som kaller pĂ„ denne. Jeg tror det skal vĂŠre mulig Ă„ kutte ned antall kall hit ytterligere. Glemte Ă„ nevne dette igĂ„r, jeg har blitt (midlertidig) frontend arkitekt i Ardoq đ 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. Egentlig ikke noe revolusjonerende, men vi trenger noen som bryr seg om frontend kodebasen. 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 (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!")]
])
: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 1
(volatile! ..)
) , til nÄr du trenger en muterbar peker, men ikke trenger alle featurene til atomervolatile!
(men eg har ikkje testa) 1
volatile!
(men eg har ikkje testa)