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

Improve performance #25

Open
merelinguist opened this issue Jul 22, 2020 · 8 comments
Open

Improve performance #25

merelinguist opened this issue Jul 22, 2020 · 8 comments

Comments

@merelinguist
Copy link
Contributor

Recent benchmarks against a similar library, devalue, read as follows:

superjson output: 179 bytes
devalue output: 116 bytes

() => superjson.stringify(obj)
1000000 iterations in 21005ms

() => devalue(obj)
1000000 iterations in 8168ms

() => superjson.parse(superjson_serialized)
1000000 iterations in 6487ms

() => eval(`(${devalue_serialized})`)
1000000 iterations in 2290ms

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

@Skn0tt
Copy link
Collaborator

Skn0tt commented Jul 22, 2020

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 [...path, head] to path.push(head) if that's possible.

@Skn0tt
Copy link
Collaborator

Skn0tt commented Jul 22, 2020

We should tackle blitz-js/blitz#10 before this to have some objective measurement I guess :D

@merelinguist
Copy link
Contributor Author

Yep! Was going to just comment on that but thought I’d set up a new issue.

@flybayer
Copy link
Member

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 superjson.stringify, but we will on the client.

That said, we could use superjson.stringify on the server and bypass the Next res.json() helper.

@Skn0tt
Copy link
Collaborator

Skn0tt commented Aug 3, 2020

I’m not so concerned about the output size difference, which I think for now is negligible, but more about the speed.

In my opinion, we should focus the other way around. UX-wise, compute cycles are cheap but network usage is expensive.

@flybayer
Copy link
Member

So we already have a slow perf report from someone using Blitz, albeit to load 20k items in one request :)

blitz-js/legacy-framework#778

@Skn0tt
Copy link
Collaborator

Skn0tt commented Aug 30, 2020

Uh-oh ... I guess we‘ll need to look into adding a bigger benchmark case ^^

@sannajammeh
Copy link

sannajammeh commented Sep 1, 2023

Is this still the case?

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

4 participants