msgspec's performance is generally on par with that of orjson. For some schemas we're faster, for some orjson is faster. For common message schemas though things should be about the same.
There are some valid reasons a user might prefer to migrate from orjson to msgspec.json instead:
For most users that aren't passing additional config options to orjson, porting should be as straightforward as swapping calls to orjson.loads to msgspec.json.decode and orjson.dumps to msgspec.json.encode. For other options we generally have a corollary, but the spelling is different. A short porting/comparison guide might be useful here.
msgspec's performance is generally on par with that of
orjson. For some schemas we're faster, for someorjsonis faster. For common message schemas though things should be about the same.There are some valid reasons a user might prefer to migrate from
orjsontomsgspec.jsoninstead:msgspecalso can handles schema validation using python type hints, similar to (but faster than)pydantic. Adding types also generally makes parsing faster, while providing stronger guarantees to the user.orjsonreleases have led to segfaults for some users (see e.g. the saga of https://github.com/ijl/orjson/issues/452, https://github.com/ijl/orjson/pull/457, https://github.com/ijl/orjson/pull/459). While in rust,orjsonis mostly a shim around theyyjsonC library, and makes use ofunsafein several places, which can let memory safety issues sneak through.msgspecis all in C so we're not necessarily better 😬, but we do seem to have a lighter history of segfault bug reports.For most users that aren't passing additional config options to
orjson, porting should be as straightforward as swapping calls toorjson.loadstomsgspec.json.decodeandorjson.dumpstomsgspec.json.encode. For other options we generally have a corollary, but the spelling is different. A short porting/comparison guide might be useful here.