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

Dynamic dispatch for storage? #109

Closed
Frando opened this issue Apr 8, 2020 · 5 comments · Fixed by #139
Closed

Dynamic dispatch for storage? #109

Frando opened this issue Apr 8, 2020 · 5 comments · Fixed by #139

Comments

@Frando
Copy link
Member

Frando commented Apr 8, 2020

Hi,
I've been thinking about whether it would make sense to remove the generic Storage<T> field on the Feed struct and instead have a Box<dyn DynStorage> object on the Feed. DynStorage would be a trait with all public methods of Storage<T>. Thus, Feed<T> would just be Feed.

Benefits:

  • More ergonomic to work with in code that uses Feed. This becomes more apparent on the branch that removes failure (From Failure into std::error::Error #102) where the generic type argument becomes really long and has to be carried through all code that uses Feed.
  • Allows to combine both in-memory and disk-backed Feeds in a container. Currently, that wouldn't be possible.

Drawbacks:

  • Cost of dynamic dispatch

I would guess that compiler optimizations might oftenly reduce the cost of dynamic dispatch if you'd only use one implementation in your code paths, but I'm not sure about it.

Opinions?

@Frando
Copy link
Member Author

Frando commented May 13, 2020

@yoshuawuyts do you have an opinion on this?

@Frando
Copy link
Member Author

Frando commented May 13, 2020

We could even have a dyn Storage for each storage (keypair, data, bitfield etc). The Node impl allows to have different storages and e.g. corestore uses this to have a different key storage for feeds it manages. I'm not sure what the cost of dynamic dispatch actually is though.

@yoshuawuyts
Copy link
Contributor

@Frando big fan of erasing types in cases like these. Think this is a reasonable direction to explore.

@bltavares
Copy link
Member

bltavares commented May 13, 2020 via email

@Frando
Copy link
Member Author

Frando commented May 16, 2020

@bltavares very cool. I did start a bit on this some time but didn't publish yet. I opened #113 with what I have. It's unfinished. Please feel very free to continue there and just push to the branch dircectly, and/or do a new clean start. I ran into an issue wrt to boxing the individual RandomAccess instances, it's explained in a comment on #113. If you have an idea on how to solve that that would be amazing. Otherwise I think we can also continue with the approach in #113.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants