Seed: Ideas for (internal) improvements

[MartinKavik]

• [ ] Try to integrate some Cheap tricks for high-performance Rust.
• [ ] Other optimization tips - johnthagen/min-sized-rust.
• [ ] [Thoughts on Rust bloat](https://raphlinus.github.io/rust/2019/08/21/rust-bloat.html)
• [ ] [Tips for Faster Rust Compile Times](https://endler.dev/2020/rust-compile-times/)
• [ ] Optimize collections:
  
  
  
  • [ ] Speed up HashMaps - e.g. use https://github.com/cbreeden/fxhash.
  
  
  • [ ] Speed up somehow also BTreeMaps and IndexMaps.
  
  
  • [ ] Replace some collections with fst (?).
  
  
• [ ] Integrate wasm-bindgen-related optimizations:
  
  
  
  • [ ] https://docs.rs/wasm-bindgen/0.2.59/wasm_bindgen/fn.intern.html
  
  
  • [ ] https://docs.rs/wasm-bindgen/0.2.59/wasm_bindgen/trait.UnwrapThrowExt.html
  
  
  • [ ] https://docs.rs/wasm-bindgen/0.2.59/wasm_bindgen/trait.JsCast.html (unchecked methods)
  
  
• [ ] Dependencies:
  
  
  
  • [ ] Update.
  
  
  • [ ] Remove unnecessary.
  
  
  • [ ] Find better.
  
  
  • [ ] [Optimize](https://rust-embedded.github.io/book/unsorted/speed-vs-size.html#optimizing-dependencies) them.
  
  
• [ ] Use compiler-specific "flags" like #[inline(..)] (?).
• [ ] Integrate some general Rust optimization tips.
• [ ] Fix Visibility and Privacy.
• [ ] Add links to doc comments (once intra_rustdoc_links is stable).
• [ ] Check examples in docs comments by compiler (doc tests - Rust docs).
• [ ] Try to get rid of interior mutability as much as possible. Use, for instance, future-signals or crossbeam or flume.
• [ ] Replace mpsc with future-signals or crossbeam or flume (if possible).
• [ ] Remove deprecated and redundant code / functions.
• [ ] Try to get rid of Box / Rc where it doesn't affect public API.
• [ ] Replace standard Cow with the beef one, if possible.
• [ ] Profiling - Time Profiling, Size profiler. (Benchmarks).
• [ ] Parallelization?
• [ ] Lazy-load parts of an app (https://github.com/seed-rs/seed/issues/246).
• [ ] Virtual DOM:
  
  
  
  • [ ] "VDOM related issues / todos" - https://github.com/seed-rs/seed/issues/293.
  
  
  • [ ] Use another strategy / VDOM alternative (?) - see:
  
  
  • Memoized DOM
  
  
  • Signals (mika, dominator, futures-signals)
  
  
  • Imba - Why is Imba so fast?
  
  
  • Svelte - basics
  
  
  • Dodrio
  
  
  • Moxie
  
  
  • [ ] Refactor.
  
  
  • [ ] Reduce web_sys calls.
  
  
  • [ ] Unchecked casts.
  
  
  • [ ] Make Node cacheable? (Related - https://github.com/seed-rs/seed/issues/443)
  
  
  • [ ] Implement VDOM-specific optimizations - keyed elements, don't rerender when data hasn't been changed, etc.
  
  
  • [ ] See https://github.com/initcrash/seed-quickstart/pull/1 for some info.
  
  
  • [ ] [Add more]
  
  
• [ ] Refactor/improve App initialization - https://github.com/seed-rs/seed/issues/277.
• [ ] Implement custom Debugs.
• [ ] Macros should be as short as possible (?) - https://github.com/seed-rs/seed/pull/455
• [ ] Refactor Makefile.toml (see the quickstart's one).
• [ ] Would immutable structures help?

[rebo]

All the above excellent brainstorming, obviously crucial to the moment is systematic profiling / benchmarking to understand the effect of any of the above potential improvements.

[MartinKavik]

_Note_: I've just added into the above list this link - https://github.com/initcrash/seed-quickstart/pull/1. Is the result of the investigation of the slow first rendering in the app with many nodes. I just though it would be interesting for you. (cc @akhilman, @rebo)

[rebo]

Regarding your Node caching comments on the pull request. This is currently working as part of the hooks infrastructure. I'll upload an example later.

[akhilman]

WebAssembly Interface Types may also change performance in the future.

[flosse]

I just compared the filesize of the counter example:

• seed v0.8.0: 383K
• yew v0.17.4: 71K
• dodrio v0.2.0: 80K
• sauron v0.34.0: 148K
• mogwai v0.3.6: 94K
• dominator v0.5.14: 58K

That's a huge difference. Does s.o. know what's the main reason for this?

All were optimized with:

[profile.release]
lto = true
opt-level = 'z'
codegen-units = 1

[MartinKavik]

I just compared the filesize of the counter example: ...

The related issue comment: https://github.com/krausest/js-framework-benchmark/pull/854#issuecomment-770836519

[flosse]

I just compared the filesize of the counter example: ...

The related issue comment: krausest/js-framework-benchmark#854 (comment)

thx!

[akhilman]

I did twiggy dominators against counter example compiled in debug mode. Here is result.
Seems like serde uses a lot of binary size. We could replace serde json by browsers's json serialization.
== update ==
Or put serde/serialization behind feature flag.

[MartinKavik]

@akhilman If you think you can remove Serde or other dependencies, I will be very glad for a PR. If not possible, then feature flag would be also nice.

[akhilman]

@akhilman If you think you can remove Serde or other dependencies, I will be very glad for a PR. If not possible, then feature flag would be also nice.

I've got deeper look and seems we can not just drop serde_json:

• serde_json used internally by Seed to handle browser history https://github.com/seed-rs/seed/issues/385#issuecomment-780051356;
• JsValue::into_serde and JsValue::from_serde also uses serde_json https://docs.rs/wasm-bindgen/0.2.68/src/wasm_bindgen/lib.rs.html#225-234.

Positive part:

• At least we know why counter so large;
• More or less complex app will have serde_json anyway.

Todomvc size comparison is not so dramatic:

• seed: 476K;
• yew: 344K.

Both includes serde_json.

[MartinKavik]

The large file size caused by Serde seems to be a known fact - https://github.com/serde-rs/serde/issues/286

If we can't remove Serde, can we replace it? I've found some potential options:

• https://crates.io/crates/serde-lite
• https://crates.io/crates/miniserde

[flosse]

* https://crates.io/crates/miniserde

This one looks promising ... probably we can use it behind a feature flag?

[MartinKavik]

• https://crates.io/crates/miniserde
  This one looks promising ... probably we can use it behind a feature flag?

MoonZoon uses serde-lite (without problems so far) instead of miniserde because miniserde is too limited - e.g. it supports only structs according to its docs. However I can imagine both can be hidden behind an associated feature flag. Feel free to create a PR if you manage to make at least one of them work and it really helps your wasm file size.