Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Help Log Messages become visible sooner #1

Open
greggman opened this issue Jan 21, 2021 · 0 comments
Open

Help Log Messages become visible sooner #1

greggman opened this issue Jan 21, 2021 · 0 comments
Labels
enhancement New feature or request

Comments

@greggman
Copy link
Owner

It's surprising how deep this whole is

Problem 1: one log -> one msg -> one update

This first problem I fixed was one call to console.log would generate one message send the main page
which would update the array of messages and trigger a redraw by react.

This had the issue that if you log a bunch of strings as in for (let i = 0; i < 10000; ++i) { console.log(i); } each of those 10k strings sent a message and each message trigger a re-draw which resulted in it taking minutes to actually display those messages.

That was fixed by batching the messages and throttling sending them.

8ce6e46

Problem 2: no yield = no processing setTimeout

A new issue remained, if you issue 10k calls to log like the example above the throttling above still prevents any messages from getting displayed until JavaScript yields because the browser is single threaded so the setTimeout for used for throttling can't actually get processed until JavaScript yields. In other words you have this

for (let i = 0; i < 10000; ++i) {
  doSomethingThatTakesTime()
  console.log(i);
}

Assume it takes 10 seconds for that loop to end, nothing gets displayed in the log because the throttling of messages is based on setTimeout and JavaScript will not process the more events until the currently running event exits

I tried to fix that by adding a 2nd throttle which uses performance.now to see if some time as passed and if so to flush the queued messages

d99ded4

This seems like it would in Chrome AFAIK because Chrome will run the iframes from another domain in another process. Unfortunately, the host for the runner is in the same domain so it can't process messages until it's iframe yields. In other words this is the current structure

[jsgist.org]
    [jsgistrunner.devcomments.org/runner.html]
        [jsgistrunner.devcomments.org/user-jsgist.html]

Because user-jsgist.html is on the same domain as runner.html they run in the same process so runner.html will not process any messages until user-jsgist.html yeilds

I could try to put user-jsgist.html in it's own domain but that would leave problem #3

Problem #3, no calls to console.log = no processing

Solution #2 attempted to let the code send messages even if the code does not yield by using performance.now to check if our time limit has passed and if so, sending the queued messages. This though is dependent on calling console.log. If you did this

console.log('hello world');
processThatTakes10Seconds();

You'd not see the message until 10 seconds have passed because there are no more calls to console.log for it to check

AFAIK the only real solution is to use a worker, send the messages to the worker, the worker won't sleep so it can do the throttling. I'm not sure that's a good solution or not. For it to work the user's process would have to send one message at a time (no queuing). The queuing would happen in the worker.

I have no yet implemented this solution

@greggman greggman added the enhancement New feature or request label Jan 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant