-
Notifications
You must be signed in to change notification settings - Fork 176
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
Slower in WebWorkers than Main Thread #401
Comments
Is setTimeout too slow? |
setTimeout has a minimum value of 4ms, as set by the standard, so it is too slow. |
Hmm interesting, there is no main event thread in the web worker thus there is no need to delay the setTimeout to a minimum. setTimeout(method,0) must be near immediate in a web worker. Have you tried this out against the message port work around? |
I agree that it makes no sense for workers, but I have doubts that they would deviate from the standard. When I get a chance to run further tests, I'll post the results here. |
Has this bug been fixed on the new release? |
@norzak this is not a bug in Doppio. This is a bug in Chrome. Please star this issue so the Chrome developers know that this should be fixed. |
The chrome bug looks like fixed. Any improvement on your end? does it work with doppio as expected? |
This is not a DoppioJVM bug. This is a bug in Chrome. Please star this Chrome issue if this is a problem you want to see fixed!
DoppioJVM runs slower in a WebWorker than the main browser thread in Google Chrome. I have yet to run tests in other browsers.
In a web worker in Google Chrome, ~45% of DoppioJVM's runtime is attributed to
(program)
, which coalesces all of the tasks that Google Chrome does itself. These(program)
blocks appear between the DoppioJVM JavaScript events in a timeline view -- periods where DoppioJVM is doing no work, and is waiting for the browser to trigger a callback. These periods are not nearly as big in the main browser thread.The culprit appears to be this bug, which makes our
setImmediate
polyfill significantly slower.. DoppioJVM schedules many tasks to complete asynchronously to keep the JVM responsive to user input, and needs a fast method for scheduling work to complete as a future browser event. This bug fundamentally limits the throughput and responsiveness of DoppioJVM. The method we use in the main thread,window.postMessage
, is unavailable in the same form in a WebWorker, so we are forced to use message ports.I haven't checked to see if the same regression occurs in other browsers. I'll check this out when I have time.
The text was updated successfully, but these errors were encountered: