Skip to content
This repository has been archived by the owner on Apr 4, 2023. It is now read-only.

Feature Request: Tree Shaking #7

Open
D1plo1d opened this issue Jun 24, 2019 · 2 comments
Open

Feature Request: Tree Shaking #7

D1plo1d opened this issue Jun 24, 2019 · 2 comments

Comments

@D1plo1d
Copy link

D1plo1d commented Jun 24, 2019

I appreciate that noise-c.wasm has been optimized for size however the web assembly is still quite a lot to send over the wire at 156KB. I am new to wasm, would it be possible to split that binary into multiple wasm's so WebPack tree shaking could remove any features I'm not using?

I expect to only use Curve 25519 ECDH, AESGCM and Blake2B for my application. So another option might be to [somehow] make a custom build with the other algorithms (eg. NewHope, SHA2) removed from the library. Is there any semi-reasonable way to do that?

@nazar-pc
Copy link
Owner

Not sure I would do that. Tree shaking is mostly useful for JS AFAIK, while the bulk of size is coming from WASM file.
In order to reduce that size, it would be necessary to reduce the list of exported functions here: https://github.com/nazar-pc/noise-c.wasm/blob/master/gulpfile.ls#L65-L220
As you can see, far from all of them are exported. Also while I would be more than happy to reduce the weight of WASM part, I don't see low-hanging fruits unfortunately. If you can come up with any PRs that bring size down significantly, I'm more than happy to consider those.

Theoretically it is possible to split WASM into multiple chunks, but it is not trivial and I'm not sure how much of duplicated contents will be still in there. Also I'm not sure tree-shaking tools will handle that properly.

Yet another alternative would be to simply create yet another build target with number of algorithms reduced to most popular ones. Might be worth supporting if it reduces binary size significantly.

@D1plo1d
Copy link
Author

D1plo1d commented Jun 25, 2019

As you can see, far from all of them are exported. Also while I would be more than happy to reduce the weight of WASM part, I don't see low-hanging fruits unfortunately.

Yes, looking through this list I am starting to see what you mean.

Yet another alternative would be to simply create yet another build target with number of algorithms reduced to most popular ones. Might be worth supporting if it reduces binary size significantly.

That would be awesome!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants