-
Notifications
You must be signed in to change notification settings - Fork 57
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
Consider using slow-json-stringify #108
Comments
I think a better way moving forward is to have this as a separate package. To do so, we would need an API to allow custom stringify integration, which I am trying to achieve here: #88 |
@hoangvvo do you have plans to develop PR? Or is there something I can help you with? |
@negezor Thanks for the offer. I actually already have the PR merged to my fork at https://github.com/hoangvvo/graphql-jit. Creating the PR should be trivial. It matters more whether there would an intent to merge it into this project (since it is possible that this is not their use cases or the current fast-json-stringify implementation is being used by some people) |
@hoangvvo do you have any numbers about how much faster Just thinking that, per your wondering if a PR for graphql-jit would be accepted, that having graphql-jit-specific benchmarks showing what a specific increase was, would hopefully pique the interest of the maintainers. |
I came across slow-json-stringify recently (via just-js using it, plus a lot of other optimizations, to get a high ranking on benchmarks), which has ~generally ~150-200% faster benchmarks over fast-json-stringify:
https://github.com/lucagez/slow-json-stringify/blob/master/benchmark.md
It requires the same setup as fast-json-stringify, of providing it a schema, albeit its own bespoke schema instead of a json schema.
But seems like this would be useful to try.
The text was updated successfully, but these errors were encountered: