Suboptimal performance of dweets on dwitter

[joeysino]

In d/11965 Cantelope brings to our attention that some dweets perform noticeably more slowly on Dwitter than they do on CodeGolf.tk

For a demonstration, compare: https://www.dwitter.net/d/11913 and https://codegolf.tk/a/366 (I observed the difference in Chrome)

Why is this, and can the loss be fixed somehow?

Are there redundant postMessage() calls being made? Are we reprocessing u on dwitter before each frame? Is it the infinite loop detector? Is it CSS?

How can we display framerate on CodeGolf.tk? What is the meaning of life?

If it is the infinite loop detector, then I think we agreed before that's it's a price worth paying. In that case, perhaps we should file a bug on CodeGolf.tk that it lets us run dweets which lock up the browser?! :evil-cheeky-face:

~Edit: I don't believe it is the loopbuster because 1) Setting window.instrument = x => x in the iframe didn't change the FPS, and 2) the loopbuster doesn't really instrument eval() expressions much anyway.~ Edit: Based on KilledByAPixel's test, I think the loopbuster may be having an effect!

[KilledByAPixel]

https://www.dwitter.net/d/14409 - Test with and without the loop protection code. (It seems to make no difference.)

[joeytwiddle]

If we care enough about this, we could enable the loopstopper only when editing (which would still satisfy its primary function: to save us from tab-freezing edits).

That would mean all dweets on display would run at full speed. And it would still protect editors. But it would not protect viewers on slow devices from heavy dweets.

(We could perhaps protect viewers on slow devices from heavy dweets with a more efficient guard, that checks the framerate after 8 seconds, rather than counting every loop iteration. It wouldn't try to protect viewers from infinite loops.)

---

Update: Doing this would break any dweets that rely on the loopstopper to run. This is the first such dweet that I noticed: https://www.dwitter.net/d/14810

[KilledByAPixel]

I implemented a new loopbuster system of my own design for CapJS

http://capjs.3d2k.com/

The code is very simple and should handle both for and while loops. This is the main part that creates a wrapped version of code with loop protection. Set maxLoopCount to a high value before calling u(t) (I use 1e5).

LoopBusted=_=>{throw Error('Frame timed out, paused update.')}
LoopBusterReplace=loopHead=>{return loopHead + "(--maxLoopCount||LoopBusted()),"}
wrappedCode = code.replace(/for[\s]*\(+[\S\s][^;]*;|while[\s]*\(/g, LoopBusterReplace)

[joeytwiddle]

Here is an algorithm that apparently the current loopbuster does not catch. Could be a good test case.

https://www.dwitter.net/d/20824