Why did tree shaking as a phrase come to exist when “dead code elimination” had been around forever?
why did "dead code elimination" come to exist when dead/dying trees have existed for millions of years?
Tree-shaking, the horticulturally misguided algorithm (2023)
41–50 of 151 posts
Re: Tree-shaking, the horticulturally misguided algorithm (2023)
#42Earlier quoted context omitted.
Important to include the preceding "With GC," In theory you can import DOM functions from runtime & call with references to dom objects now, bypassing JS to call directly into runtime (I say in theory because I'm not in the know whether this is actually possible, but GC at least brings prerequisite mechanisms to get to that point)
How does GC help with that?
I think it would enable WASM code to hold references to DOM objects that have been designed around garbage collection.
Re: Tree-shaking, the horticulturally misguided algorithm (2023)
#43Earlier quoted context omitted.
How so? There is lots of code (tree). Some of the code is not connected to the entry point (trunk). Tree shaking removes the disconnected parts (loose leaves, dead branches).
Dead branches and loose leaves are still connected to a real tree, that's why it's a misnomer. "Raking" would be a better name if you want to keep to the metaphor. Dead code elimination is the most precise term, and is already well established.
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.
Re: Tree-shaking, the horticulturally misguided algorithm (2023)
#44I'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…
Wow! Do you have numbers anywhere showing the space saved? Especially for step 6, using a Vec as a Box, I would not expect that to save much.
> Especially for step 6, using a Vec as a Box, I would not expect that to save much.
It's not that using a Vec as a Box saves anything at all. It's that generics require monomorphisation, and that eats up a bunch of space, and more instances of generic types translates into more space.
If your application uses Vec elsewhere, you've already paid the binary size price for using it. Vec is close enough to Box that the functional differences don't warrant the extra code generation.
Re: Tree-shaking, the horticulturally misguided algorithm (2023)
#45I have Blazor apps running on Cloudflare pages. They download fast and the performance is great. The load time is terrible though. I think it is unsolvable with .NET. I think the core issue is how everything is entangled by design in oo langs.
Also, the amount of money put into js is hard to compete with. Then to also have copy/paste as a lang feature in js is like cheating.
Third. With Blazor at least you still need js and skills in that area. I think this is my main issue.
Re: Tree-shaking, the horticulturally misguided algorithm (2023)
#46Earlier quoted context omitted.
How so? There is lots of code (tree). Some of the code is not connected to the entry point (trunk). Tree shaking removes the disconnected parts (loose leaves, dead branches).
Dead branches and loose leaves are still connected to a real tree, that's why it's a misnomer. "Raking" would be a better name if you want to keep to the metaphor. Dead code elimination is the most precise term, and is already well established.
dead branches and loose leaves are connected to a real tree in the same way that dead code is connected to the program in a file. if you break off the dead branch, nothing happens to the tree, just like when you remove unused code, nothing happens to the program.
Re: Tree-shaking, the horticulturally misguided algorithm (2023)
#47Tree-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 current heap of a running Lisp. An application then is an image plus a runtime. The image typically includes almost all code AND data from the memory, which sometimes creates the wish to create smaller images for application delivery. Lucid CL then included a tool, which before saving that image, removes all kinds of unused code and data, depending on some meaning of what „unused“ means. For example the symbol table may have variables, types, functions, etc. which are not referenced anywhere. A treeshaker tool might also get a list of things to remove. Thus in a graph of reachable Lisp data&code, the connections are pruned. Either a GC or a specialized piece of code then collects the garbage, shrinks memory (-> shakes the tree and everything which is cut loose is falling down) and dumps it as a possibly smaller image.
The treeshaker thus was not a compiler tool, but a tool to remove what was determined to be unused code of a Lisp heap. Remember, by default such a Lisp image would also contain a compiler, an interpreter and an implementation of a read-eval-print loop. Thus if we break (-> interrupt a thread which then provides a REPL) a running program into such a read-eval-print loop, we could still use all the code, which is in this heap (which was restored from an image). Thus it would make sense to remove the compiler too, and possibly the read-eval-print loop, too.
Re: Tree-shaking, the horticulturally misguided algorithm (2023)
#48Earlier quoted context omitted.
How so? There is lots of code (tree). Some of the code is not connected to the entry point (trunk). Tree shaking removes the disconnected parts (loose leaves, dead branches).
Dead branches and loose leaves are still connected to a real tree, that's why it's a misnomer. "Raking" would be a better name if you want to keep to the metaphor. Dead code elimination is the most precise term, and is already well established.
One is pruning dead stuff and shaking the tree is then letting them fall down. The garbage collector then takes it away.
Re: Tree-shaking, the horticulturally misguided algorithm (2023)
#49Earlier quoted context omitted.
How so? There is lots of code (tree). Some of the code is not connected to the entry point (trunk). Tree shaking removes the disconnected parts (loose leaves, dead branches).
Dead branches and loose leaves are still connected to a real tree, that's why it's a misnomer. "Raking" would be a better name if you want to keep to the metaphor. Dead code elimination is the most precise term, and is already well established.
Have you... Ever seen a tree?
And what happens when the wind blows?
Shaking and raking are hardly different in kind.
Re: Tree-shaking, the horticulturally misguided algorithm (2023)
#50I'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…
avoid floats (fixed point arithmetic saved quite a bit of space)
Can someone help me understand how this works? I thought JavaScript uses doubles for everything. Is WASM completely different in this regard?