Turbo mode not fast for reportURL

[gengshenghong]

While in turbo mode, it is faster for most of the blocks, but for reportURL, it is slower. After reading the code, I've get some ideas about the reason. The "turbo mode" works because of below code:

while ((Date.now() - this.lastTime) < 100) {
            this.threads.step();
        }

It will not yield CPU for 100ms in turbo mode and make things faster. But for reportURL, the "readyState" will NOT be changed during this 100ms. This is because Javascript is single-threaded and without yield CPU, the http readyState does not have any chance to be changed.

Process.prototype.reportURL = function (url) {
    var response;
    if (!this.httpRequest) {
        this.httpRequest = new XMLHttpRequest();
        this.httpRequest.open("GET", 'http://' + url, true);
        this.httpRequest.send(null);
    } else if (this.httpRequest.readyState === 4) {
        response = this.httpRequest.responseText;
        this.httpRequest = null;
        return response;
    }
    this.pushContext('doYield');
    this.pushContext();
};

If we use "reportURL" to communication with some hardware (which may requires real-time results), the turbo mode make it very much slower in this case.

Any idea how we can make turbo mode work for this case?

[towerofnix]

Maybe make it detect turbo mode and then do a synchronous HTTP request (rather than async)?

[gengshenghong]

yes, I've also think about using sync mode, but if it is a long time request, that may block the whole browser...

Another idea is to use webworker?

[jmoenig]

Well. Sync is out of question. People misunderstand "turbo" mode and "warp" for various reasons. It speeds up certain operations but slows down others, which is the whole point. In general Turbo mode speeds up pen-trails intensive graphics at the cost of other operations. That's exactly what's happening here, so I'm claiming it's the right thing to do. Even while an https request is going on, Turbo mode will speed up the drawing of your fractal graphics.

[cycomachead]

Couldn't the process object have a callback function? And then treat the HTTP request like a continuation?

I get that these speedups can't be universal, but it doesn't seem like this is an inherit limitation in turbo mode, right? We do have a problem when users have virtually no way of reliably determining what's going on.

[jmoenig]

turbo mode only vields every 100 ms, thus slowing down all peripheral and user interaction in order to speed up raw computation at every tick. It's perfectly clear what's happening and why this is slowing down an http request the same way it is slowing down user interaction with mouse movements and keyboard entries.

[cycomachead]

None of this is clear to average users / students, or even TAs and teachers.

[gengshenghong]

I do understand what @jmoenig means, from the code, it do will slow down HTTP or other event-based interactions (for every 100ms). But I also agree with @cycomachead , this is not easy to be understood even by teachers (if no Javascript background, even developers working with other languages may not be able to understand!).

I am not very familiar with Javascript low-level stuff also, so, I post the issue here to see whether there is any good suggestion from you experts, maybe just like a brainstorm...:)

[brianharvey]

Reopening with new tag "documentation," which will remind me of situations like this in which something obvious to Jens needs better explanation in the manual.