roact icon indicating copy to clipboard operation
roact copied to clipboard

Instance pooling

Open LPGhatguy opened this issue 7 years ago • 1 comments

One thing we should plan for in a new reconciler is experimenting with pooling of Roblox instances. Since we can keep the instance itself alongside the previous element, we should be able to reconcile from any state to any other state.

One thing that will be tricky is debugging when a stray connection is left from a userland component. Migrating more code to use Roact.Change should seal up the last big case where that would've been a problem -- GetPropertyChangedSignal. Most other cases of manual signal connections are on singletons.

I'm not sure if this was actually a performance issue, but if it works out, it could make Roact more performant in some cases than even the most carefully-optimized, hand-written code.

LPGhatguy avatar Apr 17 '18 03:04 LPGhatguy

I've attempted one method of pooling here.

CHALLENGES A major issue I encountered was that many types of userdata (Vector3s, UDim2s, Color3s, ext.) can be made with the same values and are equal when compared (==) but do not act as the same key in a table. I resolved this by implementing a functional layer on top of the original creator functions that would convert the values to a string and use that to lookup equivalent values in a cache before creating a new userdata.

SPEED Testing this implementation's speed with the built in examples (including the stress test) I noticed that it performed slightly slower than without pooling. I'm not sure how it will behave in production.

METHOD This method counts the number of properties that are the same and subtracts the total properties to rank the value of pulling an instance from the pool.

ALTERNATIVE Another method which may be quicker but not always pull the best instance from the pool would be to find the intersection of the sets of instances with the same value for a property and returning if only once instance remains. This method may be better if properties were given priorities to control the order their sets are intersected in.

CONCLUSION Lua is slow enough that it is easy to lose the advantage of pooling. Predictive techniques may make pooling more efficient, but unless kept simple they also may overcome the benefits. Lazy cleanup could be useful though to mitigate instance deletion and creation spikes.

idiomic avatar Jan 04 '19 22:01 idiomic