Clojurians Log v2
parinfer
@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.
@eraserhd average 4 ms? great performance, rust is really fast
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.
On my machine, seems consistently 1/4th the runtime of the JavaScript.
Actually, there's a lot more variance in the JavaScript. I think there's some GC going on in the longer ones.
have you done the job to use it in vim?
Yeah. In the repo, the vim script is in plugin/
Essentially there's one function, "run_parinfer" which takes a UTF8 JSON blob and returns one.
so, you haven't make it run after each buffer change?
Oh, yes, it does that.
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.
(and it registers to handle Vim's TextChanged event)
I see, so basically I should start with the cparinfer.
It's pretty simple to port it to emacs, parinfer-rust is great.
I will do it at next week.
is it possible to compile this to wasm?
so we don’t have to write js
the rust irc is super helpful if you ran into difficulties trying to
How do those benchmarks compare to other implementations.
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
slightly off topic, but subform is an amazing piece of technology. i’ve always wondered if layout wouldn’t be easier without css.