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
Adivce on reducing code size in WASM target #349
Comments
https://github.com/dtolnay/cargo-llvm-lines can be quite useful to track down where you end up with to many instantiations of some code but without an example of how your parser looks I can't really say anything specific. In combine itself, it may be possible to move partial parsing behind a feature flag, allowing you to avoid including the code for it if it isn't necessary. It may be a bit complicated to implement though. |
thank you for the reply, i'll try the tool you suggested, I've used twiggy to get a sense of what's happening and the output looks like this
but this is when i build for for dev/with debug symbols, the release build does not have any info. a typical parser function look like this
I am leaving the output above only for reference, no need to investigate deeper, I just reached out in case there is some "easy fix" that you are aware of (and would require no effort on your part besides a short comment). Thank you again for the awesome lib and your time. I'll post back in case i discover something interesting in this area |
You could try using the |
Found a s small improvement for sequence parsers #351 . I also hacked in a way to disable partial parsing via a feature flag in this branch https://github.com/Marwes/combine/tree/no_default_partial which you could try to see if and how much of a difference it makes. Can't say if it is a good idea to add, but knowing if it helps or not would be necessary first. |
Interesting results, @ruslantalpa ! How you build crate for use with twiggy? I've tried to build it with wasm32-unknown-unknown and |
@Marwes thank you, i will try both your suggestions (though in about 1-2 weeks) and report back the results. thank you again for looking into this. @klensy I basically setup the project like this
and i build it with |
@Marwes tried your new branch (though had to fork it and change the TRY_PARTIAL to pub to get it to compile) results are: in release i see not big size difference (probably due to LLVM optimizations) but in dev mode there is definitely some improvement, a bit in size but also in the twiggy output, at a glance, the number of total monomorphizations per combinator is about half. I will try to have a deeper understanding of what's going on, try things out and will report back as a reference in case it helps inform future decisions. Thank you for your time
|
According to rust/wasm docs, using generic functions can lead to a lot of bloat since the compiler creates copies of those functions.
I suspect that in my case, this is the reason why 140K in a .rs file for a parser generates about 600K of WASM bytecode.
Is there a possible solution for this (work around it by writing the parser functions differently)? It seems the most common "offenders" are
choice
between
many
combinators in my case since i use them extensively.Thank you (and thank you for the lib, it was quite straightforward to port parser from parsec)
The text was updated successfully, but these errors were encountered: