Skip to content
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

Investigate bitcode vs bincode for filesystem #99

Open
RobDavenport opened this issue May 15, 2023 · 5 comments
Open

Investigate bitcode vs bincode for filesystem #99

RobDavenport opened this issue May 15, 2023 · 5 comments
Labels
enhancement New feature or request

Comments

@RobDavenport
Copy link
Member

Currently, we use bincode.

bitcode was recently released which has better compression (size) in exchange for slightly slower speeds. Could be benefecial to switch over if the gains are big enough.

@RobDavenport RobDavenport added the enhancement New feature or request label May 15, 2023
@RobDavenport
Copy link
Member Author

@RobDavenport
Copy link
Member Author

Interestingly I ran a test with this on the 3d example and somehow came up with a bigger file:

  1. bincode + zstd: 143kb
  2. bitcode raw: 443kb
  3. bitcode + zstd: 168kb

@RobDavenport
Copy link
Member Author

Closing this for now, seems unnecessary to continue exploring this at this point

@caibear
Copy link

caibear commented Apr 29, 2024

bitcode author here, your test on Feb 4 was with an old version of bitcode (presumably 0.4 or 0.5). These old versions didn't compress very well because they serialized bits while compression like zstd operates on bytes. Luckily I have released a new version bitcode = "0.6" which compresses much better.

Using version 3de7156db381dd2fa1943d59551360819e3e27f7 because the latest version failed to deserialize, I ran some tests on example_3d.gcrom. I initially measured a small regression from bincode 160kb -> 164kb. However, after further investigation I managed to get an improvement to 115kb with a small code change.

I replaced

#[derive(Clone, Copy, Debug, Default, PartialEq, Eq, PartialOrd, Ord)]
pub struct Color {
pub r: u8,
pub g: u8,
pub b: u8,
pub a: u8,
}
impl<'de> Deserialize<'de> for Color {
fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
where
D: Deserializer<'de>,
{
let hex = if deserializer.is_human_readable() {
let hex: String = Deserialize::deserialize(deserializer)?;
u32::from_str_radix(&hex, 16).map_err(serde::de::Error::custom)?
} else {
Deserialize::deserialize(deserializer)?
};
Ok(Color::from_hex(hex))
}
}
impl Serialize for Color {
fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
where
S: serde::Serializer,
{
if serializer.is_human_readable() {
serializer.serialize_str(&format!("{:x}", self.to_hex()))
} else {
serializer.serialize_u32(self.to_hex())
}
}
}

with #[derive(Serialize, Deserialize)] which serializes the color as (u8, u8, u8, u8) instead of u32. This allows bitcode to leverage its improved compression (but has no effect on bincode). Assuming you want to keep the human readable representation, I recommend using (self.r, self.g, self.b, self.a).serialize(serializer) to achieve the same effect.

@RobDavenport
Copy link
Member Author

Thanks for looking into this. Going to re-open the issue as it will be worth it to look into it again in the future!

@RobDavenport RobDavenport reopened this May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants