Object.observe
Object.observe copied to clipboard
compatible between YuzuJS/setImmediate and jdarling/Object.observe
I'm not sure if this is an issue for here. if i put YuzuJS/setImmediate before jdarling/Object.observe. then my cpu usage will rush a high level and keeping there. (safari 7.0.6 / osx 10.9.4)
there is a simple jsfiddle without any other code. just reference two js library. http://jsfiddle.net/colder/ey6mrdfg/1/
i found the main logic in our code is looping. we give setTimeout 10ms delay. but call setImmediate as soon as enough. i think we need check if setImmediate is fake first. to ensure we not affect performance.
Since Object.observe has its own hackish way to override setImmediate the two are probably colliding. I'm not sure there is a way to actually check to see if setImmediate is the "browser" version or a shimed version.
I’m reading 99% CPU load with that shim on any code I try.
function f() {
setImmediate(f);
}
The example above gives 99% load in Safari and 2% in Chrome. Am I doing it wrong? Is there any code that uses the shim and works normally in Safari?
Hi @klimlee , If you use setImmediate and observe at same time. Be sure load observe shim before setImmediate shim.
Yes, that’s what I see on the fiddle. But, like I said, I’m getting exactly the same result without observe
. Could you provide some code that works normally? Because I’ve honestly no idea whether my code above is a correct use of setImmediate
.
I'm not sure the best practice for setImmediate
and observe
.
My issus is about http://polyfills.io. In fact I'm not use them before.
At this time, I’m not sure it’s related to observe
at all. It might as well be related to WebKit’s messaging API implementation (which the setImmediate
shim apparently relies upon, and which is known to load the CPU on recursive calls).
Besides, it’s just got worse. The same empty function (above) run on Node.js utilises 101% (!) on 0.10.x and 0.6% on 0.12.3. Thus a native implementation is just as confusing and therefore cannot be a reference.