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

Grasshopper_Toolkit: Change storing of internalised data to be stored as byte[] rather than Json #625

Open
IsakNaslundBh opened this issue Apr 8, 2021 · 0 comments
Assignees
Labels
type:feature New capability or enhancement

Comments

@IsakNaslundBh
Copy link
Contributor

Description:

Grasshopper reader/writer supports byte[]. We are already suing the mechanism of going from Bson to byte[] and back in the socket toolkit.

Idea would be to check if there is any benefit in doing the same while storing internalised data in Grasshopper.

This is changing the methods in here:

https://github.com/BHoM/Grasshopper_Toolkit/blob/9085584374c45c3b9a275a2c0959c74477c7bc0d/Grasshopper_UI/Goos/GH_BakeableObject.cs#L140-L171

To instead of writing the Json to string, instead convert to BSON then to byte[] and store that. Also then need to add support for reading this back, keeping the old reader as well to support older documents.

The benefit I can see of this would be two things (hopefully), if non of them are true, this idea can be scrapped:

  1. Speed. Time to save and open documents with vast amounts of serialised data. Keeping everything binary feels like it should be meaning a performance boost.
  2. File size. Not sure if this is actually the case, but if it would reduce the file size it would be beneficial, especially as the file size matters quite a bit for the autosave function to not stop your work from running smoothly in definitions with serialised data in them.

This is ofc not a critical issue, as functionality wise it will be the same, just a matter of a potential speed upgrade.

@IsakNaslundBh IsakNaslundBh added the type:feature New capability or enhancement label Apr 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:feature New capability or enhancement
Projects
None yet
Development

No branches or pull requests

2 participants