Forgo benchmark results

[spiffytech]

I've submitted Forgo to the JS framework benchmark suite. Forgo's performance has been adequate for my own apps so far, but I'm not really pushing the envelope. Forgo doesn't need to be "the fastest gun in the West", but we want to make sure it's not the slowest, either.

The official results won't include Forgo until the PR gets accepted, but here's what I see running select benchmarks locally. All scores are mean-average milliseconds.

	Forgo	VanillaJS	Mithril	React Hooks	Alpine
Insert 1,000 elements	170	84	121	120	285
Update every 10th row	1,100	187	278	216	239
Insert 10,000 rows	1,649	1,014	1,305	1,556	2,768

The tests discourage microoptimizing - they should reflect idiomatic usage of the framework.

• VanillaJS is obviously our theoretical maximum performance.
• Alpine is the slowest framework in several categories on the official results.
• Mithril is our closest analog. Similar component model, similar scope, manual rerenders, etc. So it should be possible for us to hit their performance.
• And React because why not ¯\_(ツ)_/¯

So anyways...

Forgo's on the slower side, with some room for improvement, especially for mutating existing elements.

Any thoughts on low-hanging fruit to target?

Here's the flamegraph for the Insert 10k test:

I don't know how to tie a specific item in that graph to which component was being rendered (short of just stepping through the debugger until I've hit a function N times), but there's clearly a lot going on.

[jeswin]

This is fantastic! I don't have any suggestions right now, but I'll look at it this week/weekend.
Let's try to get it among the fast ones.

[jeswin]

I'll devote some energy this weekend to this.

[spiffytech]

The benchmarks PR has been merged, and we have semi-official results, pending I guess whenever they run the whole suite again.

[jeswin]

This is fantastic stuff!

[jeswin]

Working on the Performance (section 1 under Keyed Results). At the same time, good to know that we're doing well in some areas (Startup Metrics - section 2 under Keyed Results). There might also be a leak somewhere, because we start off well in Memory Allocation (section 3) but then drop dramatically.

[jeswin]

I spent some time on this today, but unfortunately haven't been able to improve things. However, it looks like findReplacementCandidateForComponent() is what's killing performance. I'll investigate more.

[jeswin]

I think I know the issue.

• When we insert a keyed component, we currently go through every node to see if we need to do a replacement (ie, whether an existing node exists with the same key).
• Hence the algorithm becomes slower as the number of nodes increase; when inserting into a parentElement with 10k nodes, we run through 10k nodes to see if the key exists.

We should be able to fix this by adding a Map on the parent to handle key lookup. But it's also a tricky change; hence I'd like to do this after we merge the CRU implementation.

There is another low hanging fruit.

• We could perhaps implement component.updateAsync() or rerenderAsync() which uses the requestAnimationFrame API. If multiple prop changes happen within 1/60 of a second on the same component, we'd only need to render for the final value of the prop. As of now, we rerender multiple times. This is a fairly minor change.

[spiffytech]

I think I know the issue.

Sweet! That makes a lot of sense.

We could perhaps implement component.updateAsync() or rerenderAsync() which uses the requestAnimationFrame API

The perf boost from that would be nice, and I think the async render would be appropriate for most use cases (basically everything but unit tests, where you want to immediately make assertions when a render completes).

Were you planning to just async-ify the call to the synchronous rerender(), or did you want to explicitly track queued renders? I.e., if <Parent /> and <Child /> both enqueue renders in the same frame, what do we want the behavior to be? Should Parent's render clear the queued Child render, since it rerenders Child anyway? That'd make sense since the explicit goal is minimizing redundant renders, but it's more complicated.

If we do the maximal version of this idea, we could eliminate all the DOM-walking logic from forgo-state, which in turn makes a hypothetical forgo-mobx trivial to implement.

[jeswin]

Should Parent's render clear the queued Child render, since it rerenders Child anyway?

My initial thought was that most high frequency rerenders happen on the same element, or at the same level of nesting. For example, a list of stock tickers. And that the chances of parent and child being involved in high frequency rerenders is low. But I could be wrong.

Were you planning to just async-ify the call to the synchronous rerender(), or did you want to explicitly track queued renders?

What I was planning to do is to sort of "debounce" rerenders (within the same 1/60 * seconds) on the same element. I tried it yesterday, it's a fairly minor change. Currently rerender() and component.update() return a value to the caller, which we can't in async mode. rerenderAsync() could be a new function which internally calls rerender asynchronously - it'll have to return void.

[spiffytech]

My initial thought was...

Sounds like a reasonable assumption to me. And if we ever need a more elaborate version, I don't think it would require any API changes, so doing the simple version now works fine.

That design sounds good.

I wonder if it makes sense to make the async render the default in 4.0? With update() and updateAsync(), there's the implication that the sync one should be what people default to, vs update() and updateSync() which implies the opposite.

[jeswin]

I wonder if it makes sense to make the async render the default in 4.0? With update() and updateAsync(), there's the implication that the sync one should be what people default to, vs update() and updateSync() which implies the opposite.

The sync version returns the nodes affected as a return value, which we can't anymore. However, it's also not quite useful; so perhaps we should default to async.

[jeswin]

Now that #59 is merged, I'm gonna try to fix the performance issues on top of the new code.

[jeswin]

The way to find an element quickly based on a key is to have a Map from the key to the element index (under parent.childNodes). However, these indexes can change since we allow manual DOM manipulation.

I can't think of another way to avoid the expensive loops we have now. What can we do here - impose restrictions on manual DOM modifications?