Closed rkuklik closed 3 months ago
I may take me a bit longer than usual because I nearing the end of my final semester as an undergrad, so I apologize for that.
Of course, take your time. On that note, next two weeks I will also be less available, so no pressure. Also, good luck, hope you do well.
Hello, sorry for the delay. Given that my previous PR broke swww, I would close this PR and reopen it after I fix the breakage.
I have looked into postcard
and must say, +1 for me. I consider dependencies one of the biggest wins with Rust, and would like to introduce serde
and postcard
to common
crate. serde
is goto solution for the ecosystem as a whole and postcard
seems decent to me.
What do you think?
Hey there. I am going to slowly get back into this over the course of the following weeks.
I've thought a lot about using serde
and dependencies in general after your and @itsjunetime's comments. There's really just two problems I have with dependencies:
daemon
. This is the big one. Because the daemon
will run "forever", I would really like for it to be as efficient as reasonably possible. For example, right now, after setting a static image, we unmap the underlying memory, such that RSS
reports that just around 2.5MB are being used. I would really like to keep this behavior, and it's not going to be possible with higher-level libraries.So, in conclusion, if you think using serde
and postcard
is possible while retaining the ability to unmap the underlying image bytes' memory, let's go for it.
Hello. I will close this and get back to it when I fix the regression with socket. As to the two points:
- they increase compilation time -- this isn't super troublesome, because most users will only pay the price for this once. It does make development more annoying, but not by much since we can use debug builds.
About speed of compilation, that depends. Cargo can concurrently compile multiple crates, so the biggest slowdown is in downloading them (with the now resolver, shouldn't be a big deal). When recompiling, you only recompile your crates, not the whole dependency graph, so it shouldn't impact development (can speed it up even), with the exception of link-time optimization (which can be turned off) and macro expansion (which shouldn't be an issue, only ones we want to be using are for serde
).
- they increase resource consumption in the
daemon
. This is the big one. Because thedaemon
will run "forever", I would really like for it to be as efficient as reasonably possible. For example, right now, after setting a static image, we unmap the underlying memory, such thatRSS
reports that just around 2.5MB are being used. I would really like to keep this behavior, and it's not going to be possible with higher-level libraries.
I am not sure, why should they increase resource usage? You can stumble upon a poorly written crate, sure, but I would say using widely used and well maintained library can improve correctness and efficiency of your code. Big selling point of Rust is the ability to use high level abstractions without the penalties usually associated with them (Iterator
would be a great example).
I think it is stupid to use crates like console_error_panic_hook
which is about 20 lines of trivial
code, but for complex tasks it is beneficial to lean into other people's work.
So, in conclusion, if you think using
serde
andpostcard
is possible while retaining the ability to unmap the underlying image bytes' memory, let's go for it.
Sure. I will fix the regression and get to it. Thank you and @itsjunetime for your work.
This is probably largest part of my IPC journey. Currently very much work in progress. It will probably consist of three parts:
Serialize
impl and is crucial to get right.Given that this will basically a rewrite of all communication, I would like opinion of other people before merging, as this is quite broad.