core-estimator
core-estimator copied to clipboard
oftn-oswg
Core estimator occassionally hangs on Firefox with an Intel Core i7 5960X.
Running the core estimator on current Firefox and an Intel Core i7 5960X that has 8 hardware cores and 16 logical cores, core estimator hangs if it finds 16 cores, and then attempts to detect 32, most likely because it tries to spawn 32 simultaneous workers, which never start up. See https://bugzilla.mozilla.org/show_bug.cgi?id=1052398. If I lift the pref dom.workers.maxPerDomain to 40, then the hang is avoided.
(However most of the time, the core estimator does not get near the correct number on this cpu. Running in a sequence on Firefox, I'm getting 7,1,5,1,3,2,1,2,16,1,3,8,16)
Good catch, I hadn't realized there could be a limit. I wish the web worker limit was available to us in the API.
Idea: Maybe for each worker that is spawned, it can start with posting a message saying that we are started. Then we can have a timeout for each worker checking for the message. If we exceed the timeout, we can stop the script and go with the current estimate.
In the meantime we can hardcode in some ugly UA sniffing code and if we detect Firefox, only ever test up to 20 threads.
If Core Estimator estimates exactly 20 cores for Firefox, maybe we should add a passive aggressive console.warn("Your browser is throttling this application's access to system resources. See https://bugzilla.mozilla.org/show_bug.cgi?id=1052398 for more details and install a better browser like Google Chrome or Microsoft Edge.").
Hmm, testing on IE11 today on the 8 hw/16 logical core i7-5960X, I see that IE11 too hangs when running the core estimator live demo page, at the same point where Firefox does: spawning 16 workers was ok, and 32 workers never finishes.
Perhaps it would be possible to have the workers ping back to their creator once they start up. That way if there's no reply in fixed k seconds, the estimator could assume that that many workers is not supported, and the test would run only up to that number of threads. I agree it's ugly, but at least it's a pragmatic workaround for browsers that silently quota the number of workers.
FWIW, IE11 and Edge seem to limit to 25 workers per window or per domain (not sure which one). I did some testing in https://bugzilla.mozilla.org/show_bug.cgi?id=1241485#c0
I've been trying this with IE 11 on Win 8.1 and ran into it never finishing on the demo page a few times. Other times it started up quite a few cores and then dialled back to 8 or 4. I have an u7-4700MQ @ 2.4Ghz with 4 cores (8 with HT). I suspect this worker limit would explain the problem.
Could there be an option added to the API where we are happy to accept an upper limit on the core count? With what I want to do - detect barcodes - I'm very happy to use <= 8 cores anyway. On a low-end tablet I'd want to throttle that back to 1 or 2 cores as required and on a higher-end tablet, like a Surface Pro, I'll use as much as I can up to that reasonable limit.
