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

Msgpack as an alternative to ujson #55

Closed
vromanov opened this issue Oct 17, 2016 · 3 comments
Closed

Msgpack as an alternative to ujson #55

vromanov opened this issue Oct 17, 2016 · 3 comments

Comments

@vromanov
Copy link

What do you think about msgpack as json lib? As I know it is faster than ujson.

https://gist.github.com/cactus/4073643
https://blog.ionelmc.ro/2015/11/22/memory-use-and-speed-of-json-parsers/
https://gist.github.com/msiedlarek/4985748#file-ujson_vs_msgpack-py

(my results:
json: 32.72526153300714
ujson: 33.44454480899731
msgpack: 9.162779016012792)

I think it will be great to replace ujson to msgpack or just move ujson to another level of abstraction to have ability to choose between msgpack or ujson or smth else.

@vromanov vromanov changed the title Msgpack as alternative to ujson Msgpack as an alternative to ujson Oct 17, 2016
@seemethere
Copy link
Member

What's the advantage?

You still have to load and dump from json since msgpack is not compatible with straight json.

How does this help with the serialization and deserialization of json?

@eseglem
Copy link

eseglem commented Oct 18, 2016

It would completely replace json. And for pure speed msgpack would be interesting, though I think technically application/msgpack is not actually a valid registered mime type, is it? Not sure if its something that should actually be served out, as most things are probably going to have issues handling it.

@vromanov
Copy link
Author

@eseglem, completely agree with you.
Ok, it is no way to do it now. Thanks for your thoughts.

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

3 participants