4 ms·
Byte-compilation isn't disabled. The slowness is due to a couple things. First is the bindgen layer between Rust and C slowing down certain calls. Porting so fa
by jaccarmac 8y ago
Byte-compilation isn't disabled. The slowness is due to a couple things. First is the bindgen layer between Rust and C slowing down certain calls. Porting so far has been wide rather than deep, so Rust code ends up having to call C sooner rather than later. In addition most of the ported functions have been rewritten in a pretty naive style that doesn't take full advantage of Rust. There was some discussion in Gitter or issues about this a couple weeks back, but I cannot seem to find it tonight. Apologies.
- rcthompson 8y agoThis is something I've been wondering about. Porting from C to Rust one function at a time sounds nice, but presumably the end result would be a Rust program with an identical program structure to the original C, which as a result doesn't take very much advantage of Rust's features. Is the goal to port all the way to Rust and then refactor to actually make the code Rust-ish?
- jaccarmac 8y agoYep! Even now it's not quite as bad as identical program structure. I mean, the high-level is fairly similar, but even now individual functions can look significantly different. Emacs' C is already largely written in a high-level, macro-rich style to deal with Lisp objects (tagged pointers). So Rust already gives wins there w.r.t. more explicit types and From/Into impls over macros. And over the last couple weeks there has been discussion about replacing xml.c with a native Rust backend for XML parsing.