-
Notifications
You must be signed in to change notification settings - Fork 32
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
Comments
i found the main logic in our code is looping. |
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.
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 |
I'm not sure the best practice for |
At this time, I’m not sure it’s related to 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. |
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/
The text was updated successfully, but these errors were encountered: