111–120 of 151 posts
Isn't the tree shaking metaphor based on how some fruit trees are harvested? When you shake the tree, the ripe fruit falls off. It's not the best metaphor in that with fruit harvesting you want the fruit, whereas when storing a serialized image you discard what falls off, but alas.
The shaking is quite violent, but it doesn't hurt the tree.
Tree-shaking is such a bad misnomer. Virgil's compiler calls this "reachability analysis" and it's built into the compilation model. The compiler will parse and typecheck a program's (and libraries' code), and run initializers, but after that the compilation proceeds by exploring from the main entrypoint(s) and only reachable code is analyzed and ends in the final binary. It will happily generate a program (without r…
The name "treeshaker" for an application delivery tool possibly originated in Lisp. The first time I've found it was in Lucid Common Lisp, a (no longer available) commercial implementation of Common Lisp for UNIX. Lucid CL 4.1 in 1992 included a tool called Treeshaker. Lucid CL was one of those Lisps which have the idea of an image (see for example the "image" feature of Lisp 1 in 1960), a saved memory dump of the cu…
Why did tree shaking as a phrase come to exist when “dead code elimination” had been around forever?
"Tree-shaking" refers to a whole-program analysis where you discard entire modules and functions if they are never invoked.
They are conceptually the same, but a compiler author will likely have to implement them separately, so having two names helps.
I've kept openEtG's wasm blob (card game engine) 1. avoid floats (fixed point arithmetic saved quite a bit of space) 2. avoid hashmaps (originally used hashmaps since it was easy to port JS maps to, have since ported everything to vecs) 3. avoid strings (for awhile there were no strings, but eventually brought it in for display logic) 4. use a small allocator, like talc 5. avoid dependencies. I only use rand & fxhash…
Tree-shaking is such a bad misnomer. Virgil's compiler calls this "reachability analysis" and it's built into the compilation model. The compiler will parse and typecheck a program's (and libraries' code), and run initializers, but after that the compilation proceeds by exploring from the main entrypoint(s) and only reachable code is analyzed and ends in the final binary. It will happily generate a program (without r…
Many things in software are misnomers. Personally, I think it’s an amazing name. The first time I saw the term, I knew exactly what it was without any further research. You shake a tree to remove the loose things. In this case, it was clear that unused packages are being “shaken” from the tree.
Tree-shaking is such a bad misnomer. Virgil's compiler calls this "reachability analysis" and it's built into the compilation model. The compiler will parse and typecheck a program's (and libraries' code), and run initializers, but after that the compilation proceeds by exploring from the main entrypoint(s) and only reachable code is analyzed and ends in the final binary. It will happily generate a program (without r…
The correct general term is “dead-code elimination” [0]. Reachability analysis is commonly used do determine what code can be removed, but other methods are possible, and the analysis by itself doesn’t remove any code, that’s a subsequent step. “Tree-shaking” as commonly used implies that the granularity of the removal is functions, whereas dead-code elimination can generally be at arbitrarily fine levels, for exampl…
Google Maps uses wasm so if you need an app lots of people use that uses wasm then that's pretty big.
Google Earth is now entirely wasm but Google Earth is not that popular (https://earth.google.com/)
I've kept openEtG's wasm blob (card game engine) 1. avoid floats (fixed point arithmetic saved quite a bit of space) 2. avoid hashmaps (originally used hashmaps since it was easy to port JS maps to, have since ported everything to vecs) 3. avoid strings (for awhile there were no strings, but eventually brought it in for display logic) 4. use a small allocator, like talc 5. avoid dependencies. I only use rand & fxhash…
- Use wasm-opt from binaryen. That seems to reliably drop wasm size by ~20-30%. ( https://github.com/WebAssembly/binaryen )
- Use brotli compression for serving wasm bundles to the browser, and make sure your web server is setup to use the brotli compressed files. (Its a 1 line change in nginx, for example). Brotli drops the size of wasm bundles by about 3x. Its much better than gzip for wasm.
> Wasm makes it thinkable to do DOM programming in languages other than JavaScript Does it really? AFAIK, if I want to do any kind of DOM manipulation in say, rust, I need bindings that will basically serialize calls to be done on the JS side. So with the current incarnation of wasm, I believe you're still stuck with JS.
#[component]
fn App() -> impl IntoView {
let (count, set_count) = create_signal(0);
view! {
"Click me: "{move || count()}
}
}
I haven't tried doing direct DOM manipulation with it. But for general components it seems great.
Earlier quoted context omitted.
Tree shaking is also well established in the JavaScript world, more so than DCE, so it's pretty natural for it to be used in a wasm context.
DCE is a standard compiler optimization that's been been around since at least the 80s. It's done in multiple different ways, and "tree shaking" is just one more way. Whether the term DCE is known doesn't seem relevant to what is the most descriptive and meaningful term for this optimization.