Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upConsider making SizeLimit a trait rather than an enum #121
Comments
|
A possible further advantage would be in the Infinite case, the size_of Deserializer drops from 40 bytes to 24 bytes (assuming reading from &[u8]) and in the Bounded case it drops to 32 bytes. &[u8] // 16 bytes
bincode::SizeLimit // 16 bytes :(
u64 // 8 bytes |
|
I was actually just thinking about this! You could even go further and have the trait be something like: trait SizeLimit {
type Storage;
fn create_storage() -> Self::Storage;
fn add(&self, size: u64, storage: &mut Storage) -> Result<()>;
}
Then the Deserializer would look like struct Deserializer<R: Read, L: SizeLimit> {
reader: R,
limit: L,
storage: L::Storage,This way, the implementation of Infinite would be impl SizeLimit for Infinite {
type Storage = ();
fn add(&self, size: &u64, storage: &mut ()) -> Result<()> {} |
|
^ Then |
|
A simpler / possibly faster alternative: trait SizeLimit {
fn add(&mut self, n: u64) -> Result<()>;
}That way it doesn't need a pointer dereference for both |
|
but then implementors of SizeLimit would need to carry their own storage. This would make In addition, I don't think any implementors of SizeLimit would ever dereference self. |
|
|
Oh yeah, I suppose that does work. I was thinking of how I could expand this to also do structure size estimation, but I think I know how to deal with that now. |
This way the Infinite case would not be slowed down by all the branching in Deserializer::read_bytes:
Something like:
The compiler may be able to generate faster code in the Infinite case knowing that no branching is happening.