console.log causes frame timing issues

[quinton-ashley]

This is a problem in any sketch run on the web editor but I found it when making this frameRate test for another issue report.

https://editor.p5js.org/quinton-ashley/sketches/3qbl_XPxp

Frame timing drops are a big problem for video game development. I can't tell p5play users to not use console.log because it's important for them to be able to play test by logging values to the console while playing their game.

In addition console.log doesn't print out the value of objects and arrays correctly, which is another huge issue. #1203 #2111 It's been known about for 3 years.

It's also been almost a week since I reported issue #2113 which has been a known issue for 4 years.

If these issues aren't going to be fixed soon I will start recommending that people not use the p5.js web editor for making games with p5play. Again that's not a threat, it's just a fact that these issues are unacceptable to me, all of my students, and everyone in the p5play community. I consider these issues to be accessibility barriers.

EDIT: The p5.js editor is also unusable on mobile devices because it splits the screen into a super small editor section and a tiny preview section. This has been a known issue for 7 years #208 There's still no button to switch between the editor and a full screen preview.

[davepagurek]

This one is a tricky one. I don't have an answer yet for how to fix this, but here's some context about all the concerns we're trying to balance:

• As you mentioned, doing extra work each frame is slow, so we want to do as little as possible each frame
• The bug with console-feed in that other issue is due to the fact that it might render the element in the console asynchronously from the execution of the code. This is, I suspect, for performance, to reduce DOM updates each frame due to console logs.
• In order to store the state of an object at the time of logging, we'd need to either:
  • do a potentially deep copy of the object right when it's logged in case the original variable gets updated
  • This is complicated by the fact that objects might have circular references or complex class structures, so there's some nuance needed in deciding what to copy
  • use a console that synchronously serializes the logged data, which also means potentially slowing down rendering

There isn't much we can do in terms of parallelization, as js doesn't really have more than one thread, and to pass data to webworkers one needs to serialize it, which can also be somewhat slow.

The advice I give students is that logging data is always going to have some kind of performance tradeoff, as it involves the computer doing extra work of some kind. A good compromise might be to offer a way to pause the console when one is trying to run something fast, but enable it when you want it (without having people manually comment/uncomment console logs in their code.)

[quinton-ashley]

EDIT: This issue is mainly about why the p5.js web editor can't print out a single number each frame without frame timing drops. There is no reason inherent to JS that the p5.js web editor console is as slow as it is. There's no need for parallelization of what should be a simple task. Logging data should have a minimal cost on the cpu/gpu. The reason it doesn't have a minimal cost in the p5.js web editor is because of mistakes in the p5.js web editor's design. This can be verified by looking at other web editors that do not have this problem, such as OpenProcessing. Running the console feed asynchronously is also a mistake, not a feature that's useful for performance. The console feed could be written to synchronously and then the elements on the dom could be added later, asynchronously.

At first I thought there's no way that the problem could be related to there being too many DOM updates, but then I looked at one of the console elements!

All this html just to display one number:

<div data-method="log" class="css-kidsne">
    <div class="css-114b6w5"></div><span></span>
    <div class="css-3tmnuj">
        <div data-type="object" class="css-e393sm">
            <ol role="tree" style="padding: 0px; margin: 0px; list-style-type: none;">
                <li aria-expanded="false" role="treeitem"
                    style="color: white; line-height: 1.2; cursor: default; box-sizing: border-box; list-style: none; font-family: Menlo, monospace; font-size: 11px;">
                    <div><span style="color: white;">58.8235294117647</span></div>
                    <ol role="group" style="margin: 0px; padding-left: 12px;"></ol>
                </li>
            </ol>
        </div>
    </div>
</div>

Logging a number or an array every frame is really typical in game play testing and something I teach my students to do. I've never encountered this problem before with other editors.

I noticed that the frame drops start happening after like 10 seconds of run time. Logging just one number ever frame produces 37kb of DOM data with 600 elements.

After 30 seconds of runtime the console feed would contain 1.1MB of DOM data with a total of 18,000 elements. I'm no expert on what is or isn't a lot of DOM for the browser to process but it does seems like a lot.

For reference if a number in the console was shown using a single div, which is all that's need...

<div>58.8235294117647</div>

Then 30 seconds of runtime would only create 48kb of DOM data.

I made this sketch for testing:

https://editor.p5js.org/quinton-ashley/sketches/gEQ_V0mph

Here are some results of the methods that take the longest.

[quinton-ashley]

I've concluded that there are too many problems with the p5.js web editor for it to be useful for the p5play community. It seems like these problems will not be solved anytime soon and I'm uninterested in working on the p5.js web editor myself.

I will begin showing a big warning both on p5play.org and in my p5play starter template for the p5.js web editor that will list out all these basic usability issues.

I will recommend that people either use OpenProcessing or GitHub codespaces.

I think the p5.js web editor project leaders made a mistake prioritizing new features instead of fixing these core issues and I'm disappointed with the direction this project is currently headed. There's no valid reason these issues should still exist and I hope they get fixed in the future.