This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (3)
- # beginners (13)
- # boot (52)
- # cbus (1)
- # cider (13)
- # cljs-dev (70)
- # cljsjs (16)
- # cljsrn (124)
- # clojure (129)
- # clojure-austin (3)
- # clojure-boston (2)
- # clojure-russia (238)
- # clojure-sg (3)
- # clojurescript (119)
- # cursive (18)
- # datomic (22)
- # editors-rus (2)
- # events (1)
- # hoplon (160)
- # jobs (1)
- # jobs-rus (8)
- # ldnclj (31)
- # ldnproclodo (1)
- # lein-figwheel (4)
- # leiningen (8)
- # off-topic (3)
- # om (335)
- # onyx (29)
- # re-frame (15)
- # reagent (12)
- # robots (1)
- # yada (19)
@dnolen: I've got a rough port of the Lean Hash Array Map Trie (https://github.com/bendyworks/lean-map) done. All the basic HashMap functionality is there and it runs ~25% slower then the current implementation. I'm currently going through bugs I've found via property checking.
the only way to guarantee this in a reliable way across JS engines is to make an array initialized to null of the dimension you desire
no simple over sight I've working on getting this working then making it fast
boolean tests (cljs.core.truth_) always mean an expensive check as well as often a closure allocation
What level of perf and testing would be needed for this to even come close to replacing the current implementation of HashMap?
@alexmiller: @spinningtopsofdoom of is working on porting the new HAMT paper to ClojureScript
@alexmiller: @spinningtopsofdoom is 25% of ClojureScript HAMT even with glaring perf issues
I think some of it makes total sense and the rest probably does too, just need to look at it closer
Another win is it needs less code and less complex code (at least from the very rough port I've done so far)
thanks again for all you help @dnolen I'll let you and @alexmiller know if anything interesting comes from this experiment
Do you mean in terms of iteration and cache misses or the size of the datasctructure on heap?
hmmm I'd image that there would be memory savings from removing the
nil's as markers for nodes. IIRC js arrays size themselves based on what they store.
i.e. if you have an array of all integers it'll be more compact then any array of objects.
I know some of what happens behind the scenes in JS land when it comes to memory layout but not enough to definitively answer your question.
they try to determine at runtime whether a JS array is really unboxed integers or whatever
I fixed this in CLJS HAMTs a couple of years ago - 3-4X perf enhancement across all major JS engines
@spinningtopsofdoom: hey, I saw you’re using some code very close to ztellman/collection-check — did you make any further modifications besides adaptions for cljs? I’m pretty close to done porting it, if you feel like giving it a spin :simple_smile:
That would be awesome could you point me to the repo? The collection check doesn't show me the minimal case for some reason :disappointed:
I basically copy pasta'd and stopped when I got ClojureScripts HashMap's passing the tests
@spinningtopsofdoom: it’s at https://github.com/martinklepsch/collection-check-1 but there is a bunch of uncommitted stuff, will ping you when I pushed
@spinningtopsofdoom: pushed. to install to local
~/.m2 you need to run
boot build-jar, if you don’t have boot installed: https://github.com/boot-clj/boot#install