Performance meta-issue

[LPGhatguy]

Roact's primary goal is not performance; it's always going to end up slower than writing UI in Roblox by hand and that's okay. @AmaranthineCodices broke down rough performance in a blog post here and showed that Roact is within an order of magnitude of manual UI in at least one simple case.

That being said, there are some improvements that can be made!

Some ideas that can be fleshed out:

• Asynchronous rendering like React 16 (#18)
• Smarter context copying (part of #4)
• Pooling of elements to reduce GC pressure
• Smarter update dispatching (this is more of a Roact-Rodux issue)

[AmaranthineCodices]

We can also document some performance tips that Roact can't do on its own. One thing that I think has an effect but I've not had time to sit down and build a benchmark for is using named keys instead of the default numeric keys:

-- Write this:
{
    Child1 = someElement,
    Child2 = anotherElement
}

-- Not this:
{
    someElement,
    anotherElement
}

React recommends a similar practice when rendering lists: Lists and Keys

In Roact, the reconciler diffs children using their keys:

https://github.com/Roblox/roact/blob/bbb066316149f9b56fdf7718d48bcded7288d86f/lib/Reconciler.lua#L411-L418

If the key is determined by index, something as simple as inserting an element at the start of the list will change the index of every child, causing at least every child to be updated needlessly, or at worst causing every child to be torn down and re-rendered from scratch.

I don't know how much this actually matters in real-world applications, and I doubt it's noticeable outside of very, very large lists, but it's still a good practice.

[LPGhatguy]

I'm building a benchmarking tool now due to increased internal pressure to get a better bearing on Roact's performance problems. A bunch of people are blocked on stuff being slow v.v

It's in another branch, I'll have a PR up either today or tomorrow.