Interesant, ma intereseaza acest benchmark pentru un joc facut in JavaScript!
Observ ca totusi metoda “factory” AR TREBUI sa fie cea mai deficitara pentru ca va consuma mai multa memorie. Dupa logica mea, daca declari toate metodele obiectului in constructor, acestea o sa fie copiate pe toate instantele, spre deosebire de prototype.
E posibil ca build-ul stool sa contina o versiune mai veche de benchmarkjs sau implementarea sa fie buggy. Inca investighez asta.
Ai dreptate am facut un test cu ultima versiune de benchmark.js si valorile rezultatelor sunt mult mai apropiate acum, diferentele sunt de 5-10%, tot factory pare sa fie mai rapid, dar intr-adevar ma astept sa consume mai multa memorie.
Cam asta vreau sa aflu, cam care sunt penalizarile de performanta folosind o abordare functional programming.
O sa fac niste teste folosing DevTools CPU Profiler. Revin cu un update.
Nu m-am prins
Elm are treaba cu DOM-ul sau mai bine zis conceptul de Virtual DOM in care randezi pe bucati parti din model. Noi vorbim de optimizare de cod JS. In cazul de fata e vorba de “care din urmatoarele metode de declarare de clasa este mai rapida ca instantiere”. Right?
Din ce imi dau eu seama, @dakul propune ceva de genul: “sa comparam si functional programmingul javascript cu elm, sa vedem ce iese”. Pe de alta parte, e posibil sa fi inteles eu gresit, e peste mine jetlagul.