Hmm, I think that might be why the emscripten browser test suite sometimes stalls, we do open a tab per test, and they might overlap in time while sending requests to the same server.
On Wed, Apr 5, 2017 at 1:03 PM, Charles Vaughn <[email protected]> wrote: > I haven't found python's SimpleHTTPServer to have large file problems, but > it definitely has problems serving more than 1 request. If you've got > another tab open using that server it might cause that issue. > > > On Wednesday, March 29, 2017 at 6:41:35 PM UTC-7, Bill Yan wrote: >> >> Hi Thank you, >> >> I root caused the issue. It's not a problem of wasm, instead, it's the >> problem of the server code. >> >> when ran the program, I used the built-in python simple server: >> >> python3 -m http.server 8000 >> >> this server seems to have trouble handling large files. the wasm file is >> about 1mb. >> >> when I ran the page, it took 6 min to load. but when I refresh the >> browser, it was fast. >> >> I profiled the code, it turned out that during that 6 min, most of the >> time was spent on "idle". >> >> Then I tried the emrun program to host the wasm page. the issue went away. >> >> >> >> >> >> >> >> On Wednesday, March 29, 2017 at 12:41:22 AM UTC-7, Floh wrote: >>> >>> Without seeing the code it's hard to say what is taking so long. How >>> many megabytes of data are you generating, what are the 'loop counts' to >>> generate the data, thousands, millions, billions? How much work is >>> happening per iteration? How big are your .js and .mem files, and how much >>> data are you loading after the code has started (if any)? >>> >>> In general you need to design your application structure around the >>> browser's per-frame-callback and avoid doing anything in one frame that >>> would take longer then a few milliseconds. For instance if you have >>> long-running loops with millions of iterations, only do a few thousand >>> iterations at a time in each frame. >>> >>> Refactoring existing code for that can be hard, it helps if the code was >>> already built to handle expensive tasks in parallel (either asynchronously >>> in little work slices, or in a separate thread). >>> >>> The other option is to move the long-running code into a web worker, but >>> this is quite a bit more complex. >>> >>> Cheers, >>> -Floh. >>> >>> Am Mittwoch, 29. März 2017 02:47:07 UTC+2 schrieb Bill Yan: >>>> >>>> Hi, >>>> >>>> I just tried emscripten/wasm today. >>>> >>>> My code is an opengl/sdl program. I have a setup routine that >>>> pregenerates models and textures. And then a render loop. >>>> >>>> I learnt from the document that I can't use a plain while() loop for >>>> the main loop as it will stuck the web browser. >>>> >>>> But my setup function seems to take quit long time too, about 6 minutes. >>>> >>>> Eventually the program will run perfectly when it reaches the main >>>> loop. but the 6 minutes setup time is unacceptable. >>>> >>>> I'm wondering if there is a way to briefly give the control back to the >>>> browser during setup. >>>> >>>> For example, a pause function. so I can do >>>> >>>> >>>> setupStep1(); >>>> pause(); >>>> setupStep2(); >>>> pause(); >>>> .... >>>> >>>> >>>> >>>> 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.
