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
• Tips for Faster 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 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 (Question: Is it possible to load parts of an app dynamically? #246).
• Virtual DOM:
  • "VDOM related issues / todos" - VirtualDOM related issues / todos #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 - Performance / View Caching potential #443)
  • Implement VDOM-specific optimizations - keyed elements, don't rerender when data hasn't been changed, etc.
  • See Refactor christian-schilling/seed-quickstart#1 for some info.
  • [Add more]
• Refactor/improve App initialization - Mount takeover behavior concerns. #277.
• Implement custom Debugs.
• Macros should be as short as possible (?) - fix: C macro memory issue #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 - christian-schilling/seed-quickstart#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: krausest/js-framework-benchmark#854 (comment)

[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 Ideas for (internal) improvements #385 (comment);
• 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 - serde-rs/serde#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.