7 ms·

Thanks for the livecoding link. I assume there's some overhead in constantly checking for and applying code changes - that's probably the reason for the lower f

Thanks for the livecoding link. I assume there's some overhead in constantly checking for and applying code changes - that's probably the reason for the lower frame rate.

scottyallen 14y ago
Good point, I hadn't thought about the fact they might be polling for changes. Might be better if livecoding used an event based model to check for updates...
- akx 14y ago
  Or if it works at all like Scrubby (http://nornagon.github.com/scrubby/ http://nornagon.github.com/scrubby/) which was on HN a couple days ago, it might rewrite all constants into global lookup table indexes, which surely wreaks havoc on performance.
- dxq 14y ago
  How do you suppose event-based models are notified of changes? Ultimately you are still polling, you're just abstracting it out of your higher-level design.
enjalot 14y ago
it's not polling, its reevaluating code when codemirror triggers an event for text changing (which uses the dom underneath). the problem is from calling setInterval every time the code is evaluated, leading to way too many function calls/second