pthread initialization for 40 pthreads takes 5.8seconds because of 40 separate network roundtrips.. #21833
Comments
|
See this picture of pthread_init taking huge amount of time for 40 separate pthreads. |
|
pthreads taking this long time to initialize is completely unacceptable for a feature that saves only a little time further down the road. |
|
Do you know which resource is being repeatedly fetched? Each worker does need to load the I'm afraid I can't read anything in the picture you attached.. what is the pre-thread resource being fetched? Can you try with version 3.1.58 that was recently released, it reduces the number of resources used per thread (although the overall amount of data needed is about the same). Multi-threading is more expensive on the web than on native platforms due the current limitations of the platform so it unlikely we can get pthread start time close the native speed. However, I hope we can improve on where we are today. |
|
that resource is the web_page_highmem_worker.js file. i.e. it's emscripten's pthread system that causes the sequential delay. |
|
(it's possible we're using "no cache" flag enabled when we did the perf measurements, since that's the default in the network tab) |
|
The good news is that we eliminated that |
|
oh, I need to try the new versions if they work. I'm currently in 3.1.30 since the newer version had significant regression, but will need to try the new versions... |
|
I get some errors like: "error: expected top-level entity |
|
got newest version of emscripten to work. Figured out that "static int foobar444=0;" to the top of the file will fix the top level entity problem in draco library. newer version looks otherwise ok, but debug console window dragging will give errors... |
|
thanks, this looks like its been solved already in newest emscripten... => proposing to close the issue |
|
Great, closing. |
We expect pthreads initialization to fast, but currently it causes 5.8s delay to startup of our web page. Reason is that each pthread initialization requires separate network wide roundtrip. It would be better if the task would be done in 1 roundtrip for all 40 pthreads instead of 40 separate roundtrips executed sequentially that take HUGE amount of time.
The issue is completely invisibile on local machine. Need to have far distance machine available for debugging.
=> this feature makes pthreads completely unusable for our 3d engine.
The text was updated successfully, but these errors were encountered: