New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimization: wasted calls to view in mainLoop #641

Closed
jagare opened this Issue Jun 8, 2016 · 1 comment

Comments

Projects
None yet
2 participants
@jagare

jagare commented Jun 8, 2016

Currently the onMessage function in the mainLoop calls view(model) to create a new virtual dom given the new model after update is called see Platform.js. This virtual dom is scheduled for rendering @ rAF. However several more messages might be processed before rAF and then all but the last virtual dom created will be just waste. A more optimized way would be to post the updated model to the renderer (i.e. calling renderer.update) for lazy call of view to produce a new virtual dom just in time to produce the diff and patchset to be applied in updateIfNeeded.

@evancz

This comment has been minimized.

Show comment
Hide comment
@evancz

evancz Sep 22, 2016

Member

It is not actually 100% clear that this would be faster in general. This means more work is pushed into the requestAnimationFrame phase, so it could conceivably take a bit longer and miss the time frame. This is assuming you have one event per frame though. If things get crazy and there are tons of events, this will certainly save work, but still maybe at suboptimal times.

So it's not so obvious this will be faster! That said, the version of virtual-dom I have going with 0.18 will be using this approach because it has architectural benefits. In any case, I don't think it makes sense to track it here. Benchmarks should be done.

Member

evancz commented Sep 22, 2016

It is not actually 100% clear that this would be faster in general. This means more work is pushed into the requestAnimationFrame phase, so it could conceivably take a bit longer and miss the time frame. This is assuming you have one event per frame though. If things get crazy and there are tons of events, this will certainly save work, but still maybe at suboptimal times.

So it's not so obvious this will be faster! That said, the version of virtual-dom I have going with 0.18 will be using this approach because it has architectural benefits. In any case, I don't think it makes sense to track it here. Benchmarks should be done.

@evancz evancz closed this Sep 22, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment