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

Slower in WebWorkers than Main Thread #401

Open
jvilk opened this issue Dec 20, 2015 · 7 comments
Open

Slower in WebWorkers than Main Thread #401

jvilk opened this issue Dec 20, 2015 · 7 comments
Labels

Comments

@jvilk
Copy link
Member

jvilk commented Dec 20, 2015

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.

@jvilk jvilk added the bug label Dec 20, 2015
@ghost
Copy link

ghost commented Dec 20, 2015

Is setTimeout too slow?

@jvilk
Copy link
Member Author

jvilk commented Dec 20, 2015

setTimeout has a minimum value of 4ms, as set by the standard, so it is too slow.

@ghost
Copy link

ghost commented Dec 20, 2015

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?

@jvilk
Copy link
Member Author

jvilk commented Dec 20, 2015

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.

@neuronsupport
Copy link

Has this bug been fixed on the new release?

@jvilk
Copy link
Member Author

jvilk commented Oct 26, 2016

@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.

@neuronsupport
Copy link

The chrome bug looks like fixed. Any improvement on your end? does it work with doppio as expected?

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

No branches or pull requests

2 participants