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

Should assemblyscript-json be used in a production environment due to its massive overhead? #343

Closed
JairusSW opened this issue Feb 3, 2023 · 3 comments

Comments

@JairusSW
Copy link

JairusSW commented Feb 3, 2023

Hello there! 👋🏼
Wanted to pose this question as multiple people are experiencing memory issues when using assemblyscript-json. It seems that when parsing larger datasets, assemblyscript-json will allocate a class for each value which creates massive overhead. Taking a look at the documentation, it seems that classes are allocated for each value and these classes have copious amounts of methods, properties, and accessors resulting in a overhead in allocation, load, and store operations. When parsing a Vec3, 4 other classes (JSON.Obj, Map<string, JSON.Value, JSON.Value, and JSON.Float) are allocated along with a combined 69 methods.
Parsing 1 Megabyte of Vec3 instances (300,000) results in 1,200,000 classes with an attached 20,700,000 methods. Parsing over 1 Megabyte is simply incomprehensible.

@JairusSW
Copy link
Author

JairusSW commented Feb 3, 2023

#322
#146

@willemneal
Copy link
Contributor

The use case for this library was never meant to be for large datasets. Rather it was needed for RPC calls passing JSON strings encoding function arguments. Thus it was focused on correctness rather with little work toward efficiency.

I agree that too many allocations are used, but each class's methods are only added to the binary once. That is they are part of the code and allocation does not add another copy of the class's code, only it's data. So not sure where your 20 million methods are coming from.

Also both issues you point to don't seem related.

And in general I would advise against using this in production. This library is not maintained and is now out of date. it uses 0.19.5 and the compiler is now up to 0.27.0.

@JairusSW
Copy link
Author

Thank you, @willemneal!
This information helps a lot.
I suppose that I assumed that since it was used in the old near as sdk, it should be ready for production as in high and large data loads, but that is not the case. I did try with #146 (on a old version) and I did get a memory overflow error when I ran it 100 times, but that does not matter.
Thanks for responding and I'll close this now. Just wanted to inquire about this :)

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

No branches or pull requests

2 participants