Skip to content
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

compatible between YuzuJS/setImmediate and jdarling/Object.observe #19

Open
cncolder opened this issue Sep 19, 2014 · 7 comments
Open

Comments

@cncolder
Copy link

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
Copy link
Author

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.

@jdarling
Copy link
Owner

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.

@ghost
Copy link

ghost commented May 16, 2015

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?

@cncolder
Copy link
Author

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

@ghost
Copy link

ghost commented May 16, 2015

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.

@cncolder
Copy link
Author

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.

@ghost
Copy link

ghost commented May 16, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants