Object.observe icon indicating copy to clipboard operation
Object.observe copied to clipboard

compatible between YuzuJS/setImmediate and jdarling/Object.observe

Open cncolder opened this issue 10 years ago • 7 comments

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/

cncolder avatar Sep 19 '14 09:09 cncolder

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.

cncolder avatar Sep 19 '14 10:09 cncolder

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.

jdarling avatar Sep 19 '14 17:09 jdarling

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?

ghost avatar May 16 '15 12:05 ghost

Hi @klimlee , If you use setImmediate and observe at same time. Be sure load observe shim before setImmediate shim.

cncolder avatar May 16 '15 12:05 cncolder

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.

ghost avatar May 16 '15 12:05 ghost

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.

cncolder avatar May 16 '15 12:05 cncolder

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.

ghost avatar May 16 '15 13:05 ghost