Millisecond Forums

Addendum: We reduced the file size of the PNG files by about 40% through greyscale conversion. Now, only about 4MB of files have to be downloaded to the user side.

This does not speed up the startup process at all. If anything, startup is even slower than with full color PNGs.

This greyscale version of the experiment is available here: http://research.millisecond.com/persike/simcomparegs.web

Hi Malte,
Note that the loading time for the Inquisit Web app also includes the time to parse the script, decompress each downloaded image, and convert it to the OS's native bitmap format. The fact that shrinking the image files only lengthened the loading times suggests that the long pole might be the time required to process the images rather than download them. In any case, the timing discrepancy is longer than I'd expect, so we'll investigate and let you know what we find.

As for a live progress bar, I agree that would be useful, and we've had it on our list for a while now. Perhaps we can sneak it in sooner rather than later. It might be easier and better to have a live status message. That would tell you what Inquisit is spending all its time doing.

Regards,
Sean

Hi Sean,

we tested running the web version and the desktop version of the script on identical computers. Let me just post the results obtained on my personal notebook, attached to the 10Gbit university LAN:

(1) Desktop: 1.8 sec   (measured from the click on the "Run" button in the subject ID dialog box until first trial display)
(2) Web: 3:21 min   (measured from the appearance of the splash screen until first trial display)
(3) Web with <text> stimuli instead of <picture> stimuli:  0.9 sec   (measured from the appearance of the splash screen until first trial display: http://research.millisecond.com/persike/simcomparetext.web)
(4) Download of the ZIPped experiment: 18 sec   (measured from the click on the download button until download completion message in Chrome)

Results on other computers are very similar.

What we take away from this is that even when factoring in download times, the Web and Desktop versions produce highly dissimilar startup times. Combining the above numbers from (2), (3), and (4) we strongly suspect that the long latency is due to inefficient processing of the 400 PNG images in the web player. Download and script parsing times are negligible in comparison.

Best, Malte

On a related note... process/live status bar would be VERY USEFULl for even larger stimuli - like video which can't be compressed to mere kb! I'm running a script that loads 40 videos' at 500kb each... ouch

Hi Malte,

Thanks for sharing those results, definitely helpful.

Just to add to the puzzle, Inquisit Web and Lab use identical code for loading images (as well as doing everything else), so the quick load times with Inquisit Lab (which I've also observed) don't support my initial theory about image processing times.

We've also done our own testing and found that while the test loads in about 1 minute from a computer in the US, it seems to load much more slowly on a computer in Germany. That suggests there is something about how Inquisit is connecting and/or downloading that is slowing things down (since our server is located in the US). Still doesn't quite make sense since the time it takes to download the script file directly from the web server in Germany is about the same as it takes in the US.

We'll run more tests today. I'm thinking we may need to use an instrumented build to isolate where the lags are coming from.

-Sean

Yes, a progess bar would be useful either way.


As for the download speed issue. How is a web experiment transferred to the client PC? Are all files transferred separately or are they downloaded as an iqzip-file and then expanded on the client PC?

Anyway, do you have any way of testing as if you were overseas? We could set up a computer where you could log on via RDS.

Best, Malte

Hi Malte,
I've sent you an email with a link to a test build of Inquisit Web that includes some download optimizations. Our own testing shows a fairly substantial improvement in download times with this build, but it would be great if you could try it out and let me know what you see. 
The test build also has a first draft of a progress indicator, and it will also save a log file to your desktop that details the time spent on various operations. If download times are still unreasonably long, that log should tells us what is taking so long.

-Sean

Hehe, I ran the script with your new web player about two minutes before you posted. Just sent you an email, too.