This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-15
Channels
- # aatree (1)
- # atlanta-clojurians (3)
- # beginners (112)
- # boot (4)
- # boot-dev (1)
- # bristol-clojurians (1)
- # cider (55)
- # cljs-dev (23)
- # cljsjs (1)
- # cljsrn (7)
- # clojars (24)
- # clojure (84)
- # clojure-brasil (1)
- # clojure-china (1)
- # clojure-italy (27)
- # clojure-norway (17)
- # clojure-romania (1)
- # clojure-spec (109)
- # clojure-uk (92)
- # clojurescript (94)
- # community-development (1)
- # core-matrix (1)
- # cursive (12)
- # datascript (1)
- # datomic (23)
- # figwheel (1)
- # fulcro (17)
- # hoplon (11)
- # jobs-discuss (3)
- # keechma (6)
- # lein-figwheel (4)
- # leiningen (79)
- # lumo (32)
- # mount (42)
- # off-topic (22)
- # onyx (13)
- # parinfer (30)
- # portkey (47)
- # powderkeg (1)
- # programming-beginners (24)
- # protorepl (3)
- # re-frame (16)
- # reagent (100)
- # ring-swagger (7)
- # shadow-cljs (134)
- # spacemacs (3)
- # sql (1)
- # tools-deps (48)
- # uncomplicate (1)
- # unrepl (14)
- # yada (1)
@eraserhd if it can process 3k loc in less than 10ms, I will port it to emacs. i'm not sure about the tradeoff of the dynamic module in emacs, but i hope it is fast.
I'm new to both Elisp and Rust... but if there is anything I can do to help with this port, I would love to try.
I'm going to port the parinfer performance tests in the near future. Not feeling well enough this evening, tho. We'll see. I think there's probably plenty of room for optimization.
@eraserhd catching up on these, congrats and thanks for the port 🎉
benchmarks:
test bench_indent_long_map_with_strings ... bench: 253,694 ns/iter (+/- 28,165)
test bench_indent_really_long_file ... bench: 4,843,581 ns/iter (+/- 487,407)
test bench_indent_really_long_file_with_unclosed_paren ... bench: 4,726,135 ns/iter (+/- 490,493)
test bench_indent_really_long_file_with_unclosed_quote ... bench: 4,717,151 ns/iter (+/- 343,240)
test bench_paren_long_map_with_strings ... bench: 219,855 ns/iter (+/- 25,256)
test bench_paren_really_long_file ... bench: 4,395,875 ns/iter (+/- 366,891)
test bench_paren_really_long_file_with_unclosed_paren ... bench: 4,288,902 ns/iter (+/- 452,732)
test bench_quote_really_long_file_with_unclosed_quote ... bench: 4,368,507 ns/iter (+/- 638,843)
test bench_smart_long_map_with_strings ... bench: 255,331 ns/iter (+/- 30,632)
test bench_smart_really_long_file ... bench: 4,803,301 ns/iter (+/- 448,064)
test bench_smart_really_long_file_with_unclosed_paren ... bench: 4,802,458 ns/iter (+/- 668,362)
test bench_smart_really_long_file_with_unclosed_quote ... bench: 4,713,028 ns/iter (+/- 1,180,312)
@doglooksgood really_long_file is 2,864 lines. These benchmarks don't test marshalling/and unmarshalling with JSON or the Rust FFI, though. Just the rust package functions.
Uhuh. I'm pretty happy with it. I even got sloppy with the performance in a bunch of places to make the port parallel the JavaScript more.
Actually, there's a lot more variance in the JavaScript. I think there's some GC going on in the longer ones.
Essentially there's one function, "run_parinfer" which takes a UTF8 JSON blob and returns one.
OK, out of my meeting. What I was saying was that the "libcall" entry point is run_parinfer which taskes a JSON blob and returns one. There's a big of glue script that makes the JSON, sends it, unpacks the result, and updates the buffer. So, run_parinfer is what you would call from emacs.
is it possible to compile this to wasm?
so we don’t have to write js
I would definitely love to try compiling rust to webassembly. No clue how it will perform. I've played with webassembly for about an hour total, and know it would need a JavaScript wrapper to work.
From what I’ve heard, the wasm ffi is really slow right now. I wonder if you have “pointers” into the js objects like webgl bytearrays or do you need to copy strings?
kevin walked me through how he wired wasm/js stuff for subform-layout last week: https://github.com/lynaghk/subform-layout
it’s an alternate layout engine for CSS, and it seems to be very fast—so i’m not sure what exactly you mean by wasm ffi being slow? @snoe
in this demo, subform_init_layout
loads the wasm code from a base64 string (internally), then passes the function wrapper to a callback when done: https://codepen.io/lynaghk/pen/Jpevwj