The filesystem itself resides in JS, which can only be accessed from the
main thread. Workers therefore need to send messages to communicate with
it. However, 200ms seems ridiculously high - is that for a single read()?
Or many small reads of small amounts? If you can make a small standalone
testcase showing the issue, that would be useful for benchmarking.

A possibility is that the blocking is the issue, and the main thread is
busy with something else.

On Wed, Nov 4, 2015 at 7:57 AM, Robert Goulet <[email protected]>
wrote:

> Hi,
>
> we are using the new pthread support in Emscripten, and one thing we
> noticed is how much slower filesystem functions are when executed in a
> thread. We saw this in the documentation:
>
> *Currently several of the functions in the C runtime, such as filesystem
>> functions like fopen(), fread(), printf(), fprintf() etc. are not
>> multithreaded, but instead their execution is proxied over to the main
>> application thread.*
>
>
> I'm just trying to understand what we are dealing with. At this point I am
> guessing this is the reason why it is much slower to read a file using
> fread in a thread. We are seeing 1000x slowdowns compared to running in the
> main thread directly. For example, running in main thread, a read request
> can complete in 0.2ms, while in a thread is takes 200ms. Most likely that's
> the overhead of waiting on the main thread to process proxied requests?
>
> Is there any technical blockers preventing filesystem functions to be
> multithreaded so that they are no longer put in the main thread proxy queue?
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to