-
-
Notifications
You must be signed in to change notification settings - Fork 99
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
Memory not being freed after validation #675
Comments
Thanks for opening! There are a few In any event, I'll take a look if there is anything which is not cleaned or not capped at least |
I think you are right. I am inclined to think that the problem is with how the meta schema registry is used during the compilation process. It is cloned and resources are merged together I assume that some of the data is not properly dropped. For my own reference later:
Also - https://github.com/Stranger6667/jsonschema/actions/runs/13093817151/job/36533592518 |
After some investigation, I realized that the behavior you observed happens because of how There are also some small parts like seed values for ahash, but it is around 88 bytes on the first access. This approach is clearly far from optimal and right now I plan to reduce memory usage with #686 and one extra PR after it. A better way is to implement a proper virtual machine (#641, right now |
After performing seemingly any type of json schema validation, it seems that memory is not being freed. For example, running this version of the example code with the cap crate to print memory usage:
results in the following being printed
Using the jsonschema::is_valid approach instead results in the same behavior:
Creating a more complex schema seems to increase the memory held after the validation scope:
It seems to me that the memory should be released after the program exits the scope in which jsonschema is used, but it does not. Is there an issue with how I'm doing validation here? Or is there a problem with jsonschema itself?
The text was updated successfully, but these errors were encountered: