-
Notifications
You must be signed in to change notification settings - Fork 49
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
Binary size larger than advertized #66
Comments
The dynamic allocation example is measuring a whole lot more than just dynamic allocation: string formatting is rather heavy, and I suspect it is pulling in the panicking infrastructure as well. If you are trying to specifically measure the code size of allocators, I suggest something more targeted, like https://github.com/rustwasm/wee_alloc/blob/master/example/src/lib.rs You can built that with the
|
I have the following lib.rs file: use wasm_bindgen::prelude::*;
use wee_alloc::WeeAlloc;
// Use `wee_alloc` as the global allocator.
#[global_allocator]
static ALLOC: WeeAlloc = WeeAlloc::INIT;
#[wasm_bindgen]
extern "C" {
fn alert(s: &str);
}
#[wasm_bindgen]
pub fn greet(name: &str) {
alert(name);
} When I compile that using wasm-pack and then inspect the output using twiggy, I get:
Rows 3-8 all appear to be wee_alloc, and it adds up to 2030 bytes. That includes size_classes, but still bigger than the 1.2 KB advertised in the README. It's still much smaller than the default allocator though. |
Probably this ticket can be closed now. The size was related to a bug in Rust-lang, as rust kept dependencies to both, wee-alloc and dlmalloc. It was caused by some hard coded function name for an intrinsic in rust-lang, keeping a dependency to dlmalloc. |
When building with |
Summary
Compiling a test-app with different settings (dlmalloc and wee_alloc) the resulting binary sizes of wee_alloc builds are not as small as expected. Benefit is just 3KB, the relation is 25KB for dlmalloc-builds compared to 22KB for wee_alloc-builds with code using simple String-allocation.
see
With an application without any dynamic memory allocation, wee_alloc is adding 2500 bytes:
With an application using simple String allocation, wee_alloc is adding ca 21000 bytes, being just 3KB better than dlmalloc.
Steps to Reproduce
git clone https://github.com/frehberg/wasm-dyn-mem.git
cd wasm-dyn-mem/rust-bindgen
make build print-sizes
Expected Results
Linking against wee_alloc instead of dlmalloc I expected binaries being much more smaller and gaining larger benefit compared to dlmallic. Just, in some cases the binary is larger and the relation is just 22KB vs 25KB
Maybe wee_alloc is using some code-patterns that can not be optimized as good as expected
The text was updated successfully, but these errors were encountered: