-
Notifications
You must be signed in to change notification settings - Fork 93
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
Improve performance #25
Comments
Yeah, we'll definitely need to look into performance. I think there's a lot of low-hanging fruits to be reaped by changing stuff like |
We should tackle blitz-js/blitz#10 before this to have some objective measurement I guess :D |
Yep! Was going to just comment on that but thought I’d set up a new issue. |
One thing to keep in mind, is that on the server string<>object serialization & deserialization is currently handled by Next. So we won't use That said, we could use |
In my opinion, we should focus the other way around. UX-wise, compute cycles are cheap but network usage is expensive. |
So we already have a slow perf report from someone using Blitz, albeit to load 20k items in one request :) |
Uh-oh ... I guess we‘ll need to look into adding a bigger benchmark case ^^ |
Is this still the case? |
Recent benchmarks against a similar library, devalue, read as follows:
I’m not so concerned about the output size difference, which I think for now is negligible, but more about the speed. Obviously we’re making different design choices here which necessarily are probably slower, but I think it’d be good to see what improvements can be made in this area.
0.021005ms is pretty quick, though!
Thanks to Rich for setting up the comparison: https://github.com/Rich-Harris/superjson-and-devalue
The text was updated successfully, but these errors were encountered: