-
-
Notifications
You must be signed in to change notification settings - Fork 786
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What might a slimmer serde look like? #1412
Comments
In what scenarios would it be useful to depend on a Serde trait that has no impls? |
The general case would be something like I only need The specific case I'm looking at is structured logging in |
But bounds like that are only useful if some other library in the dependency graph enables all the impls. If you want a trait with no impls, it should be easy to shim in your own rather than removing impls from Serde's traits: #[cfg(...)]
use serde::Serialize;
#[cfg(not(...))]
use self::private::Serialize;
#[cfg(not(...))]
mod private {
pub trait Serialize {}
} |
Yeh, there's still a fair improvement to compile-times when excluding one of the |
Sounds good. On the plus side, when we stabilize const generics and variadic generics I look forward to the 50% compile time improvement from doing the array impls and tuple impls that way! |
Hi! 👋
I've been experimenting recently with whether it's possible to get a slim dependency on
serde
that still lets you work generically with its core traits. Basically enough to know thatT: Serialize
orT: Deserialize<'de>
. This usecase is probably pretty niche, so please go ahead and close it if it's not something you're interested in supporting. I've mostly been looking at compile times rather than artifact size, since we'll drop any impls that aren't actually used anyway when compilingserde
in a binary.It looks like about 50% of the compile time is spent on the code generated by these macros:
Which seems reasonable since those macros generate a lot of code.
To see how much overhead the impls have over the trait definitions, I've made a few tweaks to the core
serde
library:serde
into a new crate,serde_core
serde
just re-export theserde_core
API and forward its existing crate featuresser
andde
modules, and theser::impls
andde::impls
modules inserde_core
, but enable them by default.The split between
serde
andserde_core
was just so that libraries depending onserde
withdefault-features = false
keep the same behaviour.If a library depends on
serde_core
instead ofserde
it can disable crate features to slim down compile times. Ifserde
proper finds its way into the dependency graph then those compile times will return to normal.The results could look something like this:
serde
todayno-default-features
+ser
no-default-features
+de
no-default-features
+ser
+impls
no-default-features
+de
+impls
I'm not necessarily putting this approach forward as a good idea, I haven't thought too hard about it, but was an interesting thought experiment I thought I'd share.
The text was updated successfully, but these errors were encountered: