-
Notifications
You must be signed in to change notification settings - Fork 433
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
is it worth re-implementing this client with protobuf.js? #655
Comments
I think it'd make sense to make it an option - but I think this might be the wrong repo? I think these changes would have to be made in https://github.com/improbable-eng/ts-protoc-gen. At the moment it expects to be generated into the same folder as the |
I just wanted to test replacing the google-protobuf encoding and decoding with the protobufjs implementation. I managed to hack a POC. correct me if am wrong, but there would be no real difference in performance if we use the javascript objects generated by protobufjs instead of those generated by google-protobuf, right? |
I think that's right, but we must obviously remain compatible with both (for backwards compatibility) if we're adding this. |
I see. and agree. that said, would you have an idea where this lag could be coming from? |
Nope - the frontend isn't really my area of expertise. Maybe do some profiling? |
I want to have the ability of |
It would also make sense to do so because google-protobuf does not comply with unsafe-eval CSP, which makes it not possible to use out of the box in Web Extensions. |
instead of google-protobuf? I am seeing 1 in 10 requests suffering a considerable lag. Looking at protobuf.js, they seem to claim their implementation is more efficient than google-protobuf. the library however seems quite old so it's not clear if this still stands. is it worth re-implementing this client with protobuf.js?
The text was updated successfully, but these errors were encountered: