Dumdom er veldig mye treigere ja! Har aldri tuna performance på den, men heller ikke opplevd store problemer :man-shrugging:

Jupp, det er akkurat det som er interessant.

Det er altså ikke en kritikk av dumdom som kode, men heller av oss som utviklere, “Det må være superraskt” og så viser det seg at “søppletreigt” er raskt nok.

På jobben gjøres det iblant en del rare ting i navnet til “bedre ytelse”.

Uten at noen har gjort noe som helst for å forstå hvorfor vi har dårlig ytelse.

Jeg er generelt enig i dette, men synes samtidig at et sånt bibliotek bør starte fra et så godt sted som mulig, så man ihvertfall har mulighet til å bygge raske ting på toppen.

Man kan lett tenke seg at kode som dette eksisterer:

(swap! state assoc :a 1)
(swap! state assoc :b 2)
(swap! state assoc :c 3)

(swap! state assoc :a 1 :b 2 :c 3)

Helt klart

Tror du trygt kan kritisere dumdom-koden 😅

Er helt enig i at det er lurt (som biblioteksforfatter) å ikke bygge tregt hvis man kan bygge raskt. Problemet er at folk roper etter raskt og forkaster nest-raskest når de egentlig bare trenger søppletreigt.

Og så blir det problematisk hvis raskest medfører komplisert kode utenfor biblioteket.

Uten å helt ha tallene i hodet så er vel vdom-implementasjonen min nå ca like mye kode som dumdom, og i tillegg har dumdom flere forsøk på optimaliseringer med atomer og greier 😅

🙂

Denne Implementasjonen har bare ett atom som brukes til å spare på hooks som skal kalles

Har du profilert koden noe?

Den opprinnelige løsningen var helt funksjonell og hadde ingen atomer, men ble skrevet om for ytelse. Det som er irriterende er at problemet jeg ville løse viste seg å være et annet sted, så jeg vet ikke om det var nødvendig 🥺

Har forsøkt litt profilering, men fikk ikke så mye ut av det

mm

Jeg har en lang funksjon som jeg har lyst til å tyne litt mer ut av

Får ca 2x på create node, uten at jeg helt ser hva som kan bli bedre. Lurer på om noe er overhead med immutable data

Du slår jo opp (:renderer impl) en haug med ganger der?

(hvis jeg er på rett sted)

Og jeg sitter bare og leser koden, kjører den ikke.

Ja, det er kanskje dumt?

Jeg har tenkt at kompilatoren tar seg av sånt 😅

Jeg har lite trening i å tune performance

Det kan godt være at kompilatoren tar sånt.

Lett å prøve

Man må nesten bare prøve.

Men, bruker du noe annet en :renderer fra impl ?

:hooks

Flytta på et tidspunkt :hooks inn i protokollen, men det ble helt feil, da må protokollen hjelpe algoritmen med å gjøre jobben sin

https://github.com/cjohansen/replicant/blob/main/src/replicant/core.cljc#L210 du kunne vel ha gjort denne omvendt? i steden for å sjekke på om det du holder på med er hiccup, så kunne du sjekke om det var en string?

Kan også være alt mulig annet rart

tall, booleans, et map

right.

jeg trodde at det hiccup-greiene skulle koste mer enn det ser ut til å gjøre

Denne kalles på alle "noder" i hiccup, men memoize på den hadde 0 effekt: https://github.com/cjohansen/replicant/blob/main/src/replicant/core.cljc#L165

Der jeg vet det forsvinner for mye tid nå er i update-children hvor det gjøres for mange index-of-sjekker for å finne ut av om noder har flyttet seg. Gjorde to forsøk på å fikse det i går, men den funksjonen er lang og tung å jobbe med 😅

https://github.com/cjohansen/replicant/blob/main/src/replicant/core.cljc#L212 sikkert bare småpirk, men du oppretter et nytt map her “alltid” for {:ns ns} antar at det er sjelden du har noen verdi i ns ?

Tar gjerne imot pirk!

Skal fikse det

https://github.com/cjohansen/replicant/blob/main/src/replicant/core.cljc#L279 returnerer du et map når du egentlig kunne klart deg med en boolean?

Absolutt. Det henger igjen fra da løsningen sendte inn og returnerte tilstanden i "impl".

https://github.com/cjohansen/replicant/blob/main/src/replicant/core.cljc#L335 ser tung ut

Er run! raskere enn en loop/recur ?

Spurte om det på #C03S1L9DN i går, de mente så. Jeg tror ikke jeg så de helt store forskjellene

Dvs, jeg bytta fra doseq, som genererer masse kode

Har ikke sammenligna den med loop, men run!/`reduce` skal være raskest for vektorer. Litt usikker på om alle stedene jeg bruker den er på vektorer.

Spiller sikkert ikke noen rolle, men https://github.com/cjohansen/replicant/blob/main/src/replicant/core.cljc#L273 så trenger du ikke recur’e fordi du recur’er med new-c = nil, så du kommer alltid til samme sted?

Så du kan ta en mer spesialisert path.

antagelig noe a la det du gjør i linje 278

useless use of map ? https://github.com/cjohansen/replicant/blob/main/src/replicant/core.cljc#L284

(travesti over https://porkmail.org/era/unix/award)

Ja, den recur nil-saken hadde jeg tenkt til å fikse da jeg fiksa den andre. Men den trenger n og n-children, og sletting av noder er det koden bencher raskest på, så jeg lot den være

Jeg hadde, sånn for første lesbarhetsskyld (har lært meg det nå) foretrukket en remove-hooks

Hvor?

eksempelvis https://github.com/cjohansen/replicant/blob/main/src/replicant/core.cljc#L309

(jeg tror det er en remove-hook)

(da kunne også register-hook blitt enkere?

Det er ikke remove-hook, det er "legg til en hook for removal"

lol

Ingen ny vdom og eksisterende old vdom => unmount

Den concat ’en her https://github.com/cjohansen/replicant/blob/main/src/replicant/core.cljc#L363 er vel også litt slitsom, i allefall for meg å lese.

Kan samlokalisere register-hook og call-hooks, for det er sistnevnte som finner ut av det der

Ingen som krangler på det @slipset 😂

🙂

Jeg har som sagt prøvd å skrive den om to ganger... Vil over til å bare bruke index i vektorene, men har enn så lenge ikke lykkes

Right, for i https://github.com/cjohansen/replicant/blob/main/src/replicant/core.cljc#L255-L256 burde du egentlig kunne klart deg med indexer?

Planen min er: 1. Ignorer alle posisjoner fra start hvor nodene er like, sånn at det blir raskere å appende til en lang liste 2. Finn ut på forhånd hvilke noder som har flytta seg med én n^2 loop 3. Slå opp flytteindekser under traversering Men flyttinga gjør det litt tricky

Kunne du gjort en mellomting?

Jeg tror det skal være mulig ja, men de to concatene du fant gjør det litt 🤯 - de etterligner flyttinga som foregår i dom-en

Så lenge du ikke identifiserer en move, så er det enkelt å jobbe med index’er og så, hvis du identifiserer en move, så kan du velge den enklere, men tregere algoritmen?

Interessant

https://github.com/clojure/data.json/blob/master/src/main/clojure/clojure/data/json.clj#L176

Litt sånn som her.

(parse json strings er “lett og raskt” så lenge du ikke behøver å deale med escapes)

Jeg tror dette med ytelse avhenger veldig av domenet og hvorvidt det faktisk er en essensiell del av sluttbrukerens behov. Som tidligere teamleder for real-time 3D grafikkmotorteamet til Funcom i gamledager, når de hadde sin hjemmelagde motor, så jeg mye rart av C/C++, compiler-spesifikke triks, shader hacks og inline Assembly for å maksimere ytelsen. Samtidig som det måtte se råbra ut og helst kjøre på et bredt spekter av operativsystemer, CPU-er og GPU-er. Det var ofte vi måtte gjøre vanskelige avveininger mellom ytelse og det estetiske. Hva er "god nok" ytelse veid opp mot andre ting som brukeropplevelse, estetikk og teknisk kompleksitet er utrolig vanskelig.

Jepp, men jeg tror mange utviklere gjør det trade-off’et uten å gjøre det.

Interessant approach @slipset

Den (approachen) er jo basert på at man som regel ikke har escapes i json-strings. Vet ikke hvor ofte move nodes opptrer i dom manipulering.

Det som er interessant er at løsningen min er råkjapp på flytting. 3x enn React 😅

Men koden gjør at andre use caser blir treigere (er ihvertfall teorien). Så ut fra det høres forslaget ditt veldig fornuftig ut.

Kjører en benchmark nå med litt færre slenger-maps og map-oppslag

var det vanskelig å gjøre benchmark greia?

Leste litt fort på skrå, så ut som det var litt jobb 😕

Tror jeg må overtale min kollega til å kjøre https://github.com/chriskr/uldu i den benchmarkinga (bare for å ha det som en benchmark).

Har oppsettet klart nå, det tar litt tid, bare

5min kanskje

Ser ut til at alle tallene er litt bedre :star-struck:

kult!

Kan selvfølgelig være dagsformen til maskinen min, men alle tallene er 5-10% bedre fra i går

Det er jo bedre enn at de er 5-10% dårligere?

Absolutt 😄

De to røde boksene tror jeg handler om de concatene

Eller, altså, den delen av koden

Tusen hjertelig takk for at du leste gjennom 🙏

Bare kos! Jeg hadde også vært interessert i en IRLish code review en gang. Jeg har jo ikke brukt noe tid på å forstå algoritmene (sier ikke at jeg kunne forbedret dem), men kanskje du kunne sett noe hvis jeg var en gummi and for deg.

Ja, det hadde vært veldig trivelig å gått gjennom dette sammen, tenkte på det selv

Det er slettes ikke sikkert at mine algoritmer er de beste, jeg er ikke ekspert på området. Har bare prøvd litt forskjellig.

Jeg tar gjerne en runde på video om du er interessert. Jeg har betalt Tuple, så om du installerer den kan vi ta det over den - da kan man dele tastatur, tegne på skjermen osv.

Ja!

Fun fact: Tuple-abonnementet mitt kom opp til fornyelse i desember. Jeg var litt demotivert av å gå opp "få tilgang til software"-løypa i staten, og kikka litt rundt. Viser seg at Tuple sponser OSS-folk, så @U07FCNURX og jeg fikk sponset abonnement 😄

Kult! Du er kanskje på jobb? Jeg har fri og er ledig nå og resten av dagen.

Gi meg ti min?

👍

Hvilke DOM-operasjoner tror vi det skjer mest av generelt? Det er kanskje vanskelig (eller nærmest umulig?) å svare på. Men hvis det kan besvares (eller estimeres?) kan det kanskje informere visse prioriteringer og avveininger.

Sikkert noen som har undersøkt. Hvis du kan instrumentere et sånt bibliotek i en litt komplisert app burde du få noen innsikter.

Jeg kan ihvertfall finne ut av hvilke primitiver som brukes mest ved å instrumentere denne: https://github.com/cjohansen/replicant/blob/main/src/replicant/dom.cljs

Og kanskje det finnes noen triks for å gjøre om enkelte av de treigere operasjonene til en av de raskere operasjonene, om ikke i biblioteket så på brukersiden i praksis etter litt opplæring. Det gjorde vi ofte med 3D grafikkmotoren: vi "castet" om dyrere operasjoner til billigere operasjoner. Eksempelet til @U9MKYDN4Q på "replace all rows" med og uten nøkler fikk meg til å tenke på det. I Clojure kan det kanskje finnes noen overraskende ytelsesforskjeller mellom bruken av lists og vectors, for eksempel når man genererer eller leser "front-to-back" vs. "back-to-front."