rebo
commented
4 years ago Given the above I am looking for efficiencies that can be made that have the following characteristics
1) Can be applied generally to all apps. 2) Don't require massive structural changes to either Seed or the App's architecture. 3) Continued use of a declarative way of writing seed apps.
Some suggest that removal of the virtual dom is the way forward, certainly many frameworks have success in this area (Svelte/Solid/Imba) and some in the rust world (Valorie). However having implemented a dom-less Seed it enforces a huge amount of architecting and re-engineering that I am still unconvinced it is viable more generally and is better left to other frameworks being built from scratch.
That said there are things that we can learn from the 'domless' approach and we can actually benefit directly even though a virtual dom is still being used.
What a domless architecture does
A domless architecture has 2 phases, a paint phase and an update phase. The paint phase is pretty much identical to any framework (including seed), it builds the dom view in the browser based on a declarative representation.
Where the architecture is different is in the update phase, events/mutations to state directly cause browser dom effects and directly update the view on screen.
The advantage of this is clear, if state that determines the class of an element has changed then this will only change the class attribute in the browser and do nothing else. There is no problem of inefficiently building a virtual dom or inefficiently reconciling because these are not created to begin with.
How can Seed learn from this?
Even though Seed does have a virtual dom we can actually apply the same principle. We can render as per the virtual dom however on specific updates we can still reactively affect the browser directly.
In order to do this we need a way of determining that a specific state has changed which both is representable in the virtual dom view function as well as scheduling update code if that state changes in the future.
We can do this using Seed hooks.
Updating the Seed benchmark.
Because we want to represent reactive labels as well as selection state we change the Row definition from this:
struct Row {
id: ID,
label: String,
}to this:
struct Row {
id: ID,
selected: StateAccess<bool>,
label: StateAccess<String>,
}This creates two state variables that hold a String and a bool. The reason we are using Seed hook state variables is that they can be observed and reacted to which will be used to directly update the browser dom.
The label
In order to react to changes to the label directly we use the reactive() method on the StateAccess value. in the row view we change from this:
a![C!["lbl"], &row.label],to this:
a![C!["lbl"], row.label.reactive()],This always returns the state of the label for the virtual dom, however it also schedules an update to the relevant element whenever label is updated.
Updating the label is handled as per normal seed in the update function. We change from this:
Msg::Update(step) => {
for position in (0..model.rows.len()).step_by(step) {
model.rows.get_mut(position).unwrap()
.label += " !!!";
}
},To this:
Msg::Update(step) => {
for position in (0..model.rows.len()).step_by(step) {
model
.rows.get(position).unwrap()
.label.update(|label| *label += " !!!");
}
orders.skip()
}This simply changes from mutating label directly to updating it via the state's update method.
The result of this is as follows. On initial render the vdom is created as normal, on subsequent updates it will directly modify the dom node contents with the contents of label.
The class selection
In order to react to changes to the selected row directly we use the reactive_class() method on the StateAccess value. in the row view we change from this:
tr![
attrs!{At::Class => if is_selected { AtValue::Some("danger".into()) } else {
AtValue::Ignored } },
...tr![
row_selected(row.selected).reactive_class(),This uses a row_selected() reaction in order to render a class in response to selection changes as per this function:
#[reaction]
pub fn row_selected(selected_state: StateAccess<bool>) -> Reaction<(At, AtValue)> {
if selected_state.observe() == true {
(At::Class, AtValue::Some("danger".into()))
} else {
(At::Class, AtValue::Ignored)
}
}if the selected state is true, it renders a "danger" class attribute snippet.
Finally the update function is changed to reflect the selected state being stored on the row as well as the model.
We change from this :
Msg::Select(id) => model.selected = Some(id),to this:
if let Some(old_id) = model.selected {
model.rows[Row::position(old_id, &model.rows)]
.selected
.set(false);
}
model.rows[Row::position(id, &model.rows)]
.selected
.set(true);
model.selected = Some(id);Now this is somewhat more complex because we are setting the selected state on the row directly in addition to storing it on the model. We de-select the state on the old row and re-select it on the new row.
The effect of these changes.
These relatively small changes to the seed app leveraging the reactive features of the Seed hook state variables result in the following improved performance:
I have also made similar improvements to the swap_rows bench. As you can see partial update and select rows are now nearly as performant as vanilla-js. And much more performant than either React or Elm. There is some small additional cost in initial creation of the rows.
I will update this issue as I identify more performance improvements.
.
MartinKavik
arn-the-long-beard
flosse
zzau13
evbo
JS Framework Benchmark
The current de facto standard benchmark for measuring the performance of front end apps seems to be https://github.com/krausest/js-framework-benchmark.
This is a fairly straightforward benchmark covering a number of actions a front-end framework would typically perform.
The key advantage of this benchmark is the large number of current frameworks represented as well as an easy to run benchmark runner.
This benchmarks renders a long list of three random words and completes a number of operations. Typically the list is 1000 rows long.
The Seed benchmark on the site is an old one from Seed 0.6.0. The Seed code is for this project is representative of well written seed code therefore I have analysed against this.
The purpose of this issue is use the benchmark to:
a) Understand the performance profile of existing seed. b) Implement some ideas (perhaps from other frameworks) to improve this profile.
In this first post I will discuss some specific bench mark tests in order to build understanding for (a) above. In the next post I will show some possible improvements.
Existing results
Here are the results on the benchmark site for seed along side the top 3 ranked frameworks (typically vanillajs is one of them) as well as Elm and React.
as you can see Seed is competitive with React/Elm for some of these benchmarks but for several it is substantially slower. Specifically
partial updateselect_rowandswap rowshave very poor comparative performance.I believe the reason for this is primarily down to Seed's rendering architecture. (However something I am unclear on is why Elm does not have the same issues as I understand Elm and Seed have similar rendering architectures).
To be clear what I mean by "rendering" consists of the entirety of executing the
updatefunction,viewfunction, as well as the virtual-dom reconciliation and browser api interaction that occurs afterwards I..e everything that has to happen in order for an effect to appear on the screen.How Seed renders
What happens when Seed renders is that after the update function has mutated the app
Model, the top levelviewfunction is called, this in turn calls many other view functions until the entirety of virtual dom is built from scratch. The virtual dom being a tree ofNode<Msg>Once this
Node<Msg>tree has been built it is reconciled (diffed) against the old virtual dom and this results in actions to update the real browser dom via the browser api.This has the effect that as your view tree becomes bigger and bigger the app becomes slower to both build the dom tree and reconcile the dom tree with the old stored dom tree. This cost is paid no matter how small an update you wish to process.
Now as long as your view can be built and reconcillled within 16ms you are going to effectively have 60fps response anyway. So often this is not going to be a problem. Usually this is actually the case and these issues wont rear their ugly head. That said it is still worth considering these issues and possibly improve this situation.
Small change - Big Cost
Because any change causes the rebuilding of the entire
Nodetree, this is most inefficient when you have a tiny change that might only affect a small part of the browser dom.This "small change-big-cost" can be seen in the case of the
partial updatebenchmark. What this does is simply add "!!!" to the end of every 10th row's label. The current benchmark seed app updates every 10th row's label String field by appending "!!!". Theviewfunction then rebuilds the entire view from scratch, iterating over 1000 rows and building each one viaview_row().This is inefficient because 99% of the rows are unchanged however they are all "rebuilt" because that is how the view function works. There is an additional cost in reconciliation, again 99% of the virtual dom tree has not changed however each node has to be compared to see if it actually has.
This results in a render time of 525ms. Compared to 133ms for vanilla seed and 209ms for react.
An even more extreme effect of this can be seen in "select row". This simply adds the class
dangerto the clicked on row, and removes the class from any existing row.The seed time for this (at 16x slowdown) is
862mscompared to22msfor vanillajs and 113ms for react. Interestingly Elm is takes41ms.So what is vanillaj-s and react doing in order to prevent the larger 862ms cost?
vanilla-js
Vanilla-js simply mutates the dom nodes directly, it is not part of a framework and therefore does not need to represent a virtual dom.
React
Although react has a virtual dom, it is able to save approximately 85% of the work by using the concept of components. This is a concept that seed does not directly have or utilise. Basically a React's virtual dom is a hierarchy of components, these can be selectively rebuilt on the proviso that any child components are also rebuilt.
This means that in the equivalent react app, if a row is a component then only that row needs to be rebuilt on a change that affects that row because it has no children. This means that the entire virtual dom does not need to be reconstructed and therefore reconciliation cost can similarly be truncated.
The reason why react is not as good as vanilla JS is because it still has to rebuild the entire row and do some reconcillation.
Elm
I do not know why elm is so performant here (someone with knowledge of how Elm works might be able to help?). I thought it followed a similar model to Seed in that the entireity of the virtual dom is rebuilt each update. However this cannot be the case because 41ms (at 16x slowdown) is vastly quicker than Elm takes to complete the create rows test in the first place.
In the next post I will write up some advances in these areas.