Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tree-shaking, the horticulturally misguided algorithm (2023)

wingolog.org

Post reply on HN
Print view View original

11–20 of 151 posts

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#11

Post by 01HNNWZ0MV43FF »

FrustratedMonky wrote: post #8

Maybe off-topic. But can't you use WASM to create GUI's like Photoshop, with no JavaScript or DOM? Isn't the bigger goal of GUI's on WASM is we can jettison JavaScript/DOM and go back to writing GUI's like 10-20 years ago, with simpler libraries. Like SKIA, or something. Using non-web GUI libraries, since they could be compiled to WASM and run in web. EDIT: Native. I mean pre-web, when GUI libraries were native, ever…

It'll have to be GPU accelerated somehow, outside the wasm boundary. At 1080p it's hard to make pixels move fast enough to get away with CPU rasterization.

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#12

Post by __s »

01HNNWZ0MV43FF wrote: post #10
__s wrote: post #3

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…

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.

Unfortunately nothing concrete, it's a few kb here & there. I'd estimate I've saved ~300kb overall. I'd have to go back to compare these things. Removing floats saved more space than I expected

Also important is configuring compiler correctly,

  [profile.release]
  opt-level = "z"
  lto = "fat"
  codegen-units = 1

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#14

Post by internetter »

The big utility of WASM for me, like OP hints at, is bringing things that would be infeasible to port to the web to it, like, say https://pgaskin.net/kepubify/ and other conversion tools (eg ffmpeg-wasm). Much preferable to downloading something or uploading a file to some random person’s server

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#15

Post by kentonv »

This article is very correct: Wasm has a code size problem. This is a problem in browsers because all that code has to be downloaded to start the site. It's also a problem for serverless architectures, where code is often loaded from cold storage to a specific server on-demand while a client waits.

Tree-shaking might help, but I feel like it's only an incremental optimization. Fundamentally the reason Wasm programs are so bloated is because they have to bring their whole language runtimes and standard libraries with them. In contrast, with JavaScript, the implementation and basic libraries are provided by the browser. But obviously the browser can be expected to have language runtimes for every language pre-loaded...

... or... could it?

I think we need to consider another approach as well: Shared libraries and dynamic linking.

WebAssembly supports dynamic linking. Multiple Wasm modules can be loaded at the same time and call each other. However, many Wasm toolchains do not attempt to support it. Instead, they are often design to statically link an entire program (plus language runtime) into a single gargantuan module.

Pyodide (CPython on Wasm) is a counter-example. It is designed for dynamic linking today. This is precisely why Cloudflare Workers (a serverless platform) was recently able to add first-class support for Python[0]. (I'm the tech lead for the overall Workers platform.) A single compiled copy of the Pyodide runtime is shared by all Workers running on the same machine, so it doesn't have to be separately loaded for each one.

If dynamic linking were more widely supported, then we could start thinking about an architecture where browsers have various popular language runtimes (and perhaps even popular libraries) preloaded, so that all web pages requiring that runtime can share the same (read-only) copy of that code. These runtimes would still run inside the sandbox, so there's no need for the browser to trust them, just make them available. This way we can actually have browsers that have "built-in" support for languages beyond JavaScript -- without the browser maintainers having to fully vet or think about those language implementations.

[0] https://blog.cloudflare.com/python-workers

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#16

Post by skywhopper »

As things go along, I’m more and more mystified by WASM’s apparent design. It feels like 1996 Java for applets, but without the built-in GC, stdlib, or even the most basic hooks into the browser. Which means it’s basically useless for what I assume its goal is, of letting you use languages other than JavaScript to code a web page. Without trivial DOM access, what’s the point?

Other proposed usages like for FaaS-style edge widget computing honestly don’t make a lot of sense. Why target an artificial VM for that purpose instead of existing architectures that work just fine with less overhead.

For compute that could happen in either the browser or the edge, maybe, but how much is that level of portability really realistic or worthwhile? I’m guessing it might be in a few narrow cases, but it’s not going to be a common pattern.

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#17

Post by beepbooptheory »

kentonv wrote: post #15

This article is very correct: Wasm has a code size problem. This is a problem in browsers because all that code has to be downloaded to start the site. It's also a problem for serverless architectures, where code is often loaded from cold storage to a specific server on-demand while a client waits. Tree-shaking might help, but I feel like it's only an incremental optimization. Fundamentally the reason Wasm programs a…

I think I agree overall, just want to point out that with Wasm, you still end up using a fair bit of the built-into-browser js to accomplish things not purely computational. Especially in this context with Hoot [1], where things like appendChild are external functions you call inside the scheme. One could theoretically do this for much of the js standard library in any kind of wasm context.

1. https://spritely.institute/news/building-interactive-web-pag...

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#18

Post by nextaccountic »

kentonv wrote: post #15

This article is very correct: Wasm has a code size problem. This is a problem in browsers because all that code has to be downloaded to start the site. It's also a problem for serverless architectures, where code is often loaded from cold storage to a specific server on-demand while a client waits. Tree-shaking might help, but I feel like it's only an incremental optimization. Fundamentally the reason Wasm programs a…

Does browsers support wasm with dynamic linking?

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#19

Post by kentonv »

nextaccountic wrote: post #18
kentonv wrote: post #15

This article is very correct: Wasm has a code size problem. This is a problem in browsers because all that code has to be downloaded to start the site. It's also a problem for serverless architectures, where code is often loaded from cold storage to a specific server on-demand while a client waits. Tree-shaking might help, but I feel like it's only an incremental optimization. Fundamentally the reason Wasm programs a…

Does browsers support wasm with dynamic linking?

Yes.

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#20

Post by paulddraper »

titzer wrote: post #2

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…

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).

Post reply on HN