3 ms·
Very cool project! > the bottleneck in performance turns out to be the React frontend. It is the time taken by the React frontend to render execution updates t
by westoncb 5y ago
Very cool project!
> the bottleneck in performance turns out to be the React frontend. It is the time taken by the React frontend to render execution updates that dictates the fastest possible execution speed.
Why have React re-render each time execution updates? I don't think a user could make use of an updated visualization more than a few times per second, so it seems possible to re-render at a fixed rate (or at least capped, e.g. via 'debouncing' which ever function triggers the state update) while letting execution run relatively independently.
Also: could you say more about what kinds of the things the visualizer is capable of showing? I checked out the examples for each language and can get some sense of its range from that but I'd be curious to know more. (For example, when I was working on a program state visualizer I opted to provide visualizations of particular data structures, e.g. lists, trees, tables, maps etc.)
- nilaymaj 5y agoYou're right, 5ms updates aren't really any more useful than 20ms updates. Although for the current esolangs `React.memo` serves most 5ms use-cases, I'll be happy to implement fixed-rate updates or debouncing when a visualizer gets too complex for simple optimizations. Theoretically, the visualizer window can show anything I think - as long as the required props support structured cloning[0], it's really just a React component. Performance is the only limit, but the above methods will help when that limit is reached. A Leaflet.js map for the Taxi[1] esolang will be interesting to implement, for example. [0] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... [1] https://bigzaphod.github.io/Taxi https://bigzaphod.github.io/Taxi