Alternative to polling

[gr0uch]

Hi, I would like to use a polyfill for Object.observe, but I'm concerned about dirty checking performance.

In this project, there is a method Platform.performMicrotaskCheckpoint() which must be manually called. I wouldn't mind having the option to disable polling and manually calling some method to trigger a dirty check.

[MaxArt2501]

This has already been asked, but unfortunately that would be outside of the scope of this polyfill.
Being a polyfill, its aim is to replicate the native implementation of the feature as faithfully as possible.

This is also because you can use it in your projects without (or minimally) worrying about the moment the environment on which the project run will start supporting Object.observe. I'll remind that this polyfill does not replace any existing implementation of Object.observe, so any extension would not be loaded anymore.

But fortunately this shim is open source! So feel free to take any bit of code that you may need to perform your dirty checks - I could give you some assistance in that.
And of course, you can always fork this repository.

[gr0uch]

I'm curious if my concern is valid or not, I haven't actually tested the performance. Would it be slower to observe a lot of small objects, or one large object?

Some perspective: zloirock/core-js#33

[MaxArt2501]

Define "large".
It doesn't matter how big an object is in memory, but rather the number of its properties.
You may have a bit more overhead with many objects, because a forEach is performed on the observed objects. So, if you observe 1000 objects with one property, it's definitely slower than observing one object with 1000 properties, with 2000 callback calls instead of 1001.
But I think it's quite small compared to the actual task of dirty checking, which is performed 1000 times anyway.

I always think of performing some speed tests but I still have to find the time 😭

As for requestAnimationFrame overhead, that's why this polyfill uses just one animation loop for all the observed objects, so the actual overhead is pretty much negligible.
It's not a problem of rAF, but rather of the nature of the polyfill itself. If the alternatives are setImmediate or setTimeout(..., 0) or process.nextTick, rAF is definitely the best choice, as it doesn't clog the CPU with continouos checks and it also stops when the browser tab isn't focused (that's especially good for mobile devices).

[gr0uch]

Interesting. I would like to contribute some benchmarks, to see if its viable for real world use :)

[gr0uch]

I came up with a simple test, on my machine I get ~24 Hz in Firefox and ~152 Hz in Chrome. It's probably not a fair comparison between different browsers though.

[MaxArt2501]

That was nice, thank you.
I got the same values, plus ~52 Hz in IE11.
I also got 26-27 Hz on node 0.10.39, and 27-28 with the "lite" version.

Comparisons between browsers are totally a fair game, anyway, because that's where the the polyfill will run.
I think I will make more tests regarding the memory occupation too.

[gr0uch]

I think what would also be interesting is comparing between Chrome 34 which didn't have Object.observe enabled, and the latest Chrome. I'm less concerned about mem usage and more about cpu usage and execution speed.

[MaxArt2501]

Closing this while opening #11.