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
Integration of orjson
for (much) faster JSON encoding and decoding
#358
Integration of orjson
for (much) faster JSON encoding and decoding
#358
Conversation
…into orjson_integration
for more information, see https://pre-commit.ci
…into orjson_integration
for more information, see https://pre-commit.ci
…into orjson_integration
I don't have a problem with this, but it should be made an optional alternative rather than a requirement. In other words, the code should check if orjson is installed and use that if it is, and if not, fall back to standard json. |
Sounds good, I will make that change. |
orjson
for (much) faster JSON encoding and decodingorjson
for (much) faster JSON encoding and decoding
I want to write some more tests before it is merged. I've marked it as WIP and will indicate again when it is ready. |
for more information, see https://pre-commit.ci
…into orjson_integration
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
…into orjson_integration
orjson
for (much) faster JSON encoding and decodingorjson
for (much) faster JSON encoding and decoding
Re-writing a new Additionally, I have fixed some of the CI issues with pre-commit and pylint. This should be good to go now. |
Summary
This PR switches monty from using the standard JSON
encode
anddecode
functions, to using the equivalent in theorjson
package (see https://github.com/ijl/orjson). This greatly speeds up bothMontyDecoder
andMontyEncoder
.One important note is that I elected to keep the fact that MontyDecoder/Encoder subclasses
json.JSONDecoder
andjson.JSONEncoder
respectively. I think this effectively communicates that both custom classes can still be used with json.dumps/loads as the passedcls
argument.I will also point out that this change was motivated by slowness issues in the new Materials Project API from decoding large objects.