You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Precompute every part of the UI state that can be statically determined, with the hope that the performance will be much better when only the minimal amount of change has to actually occur when the terminal application is running.
For instance, instead of the pretty-printer width option changing dynamically while resizing the > window, I now precompute the resulting states for a fixed set of widths (e.g. 40,50,60,70,80).
Current efforts are being done in a separate branch.
Current drawbacks:
The precomputed binary is very large even for medium examples (e.g. 500mb for Windows.hs) and this has to be loaded into memory when running the TUI
Even for small examples when size is OK (e.g. 50mb for ALU.hs), the TUI turned out to be much more laggy! (profiling needed)
After this is done, if time permits, we should investigate opportunities for parallelization of the few computations that remain on the UI part.
The text was updated successfully, but these errors were encountered:
Precompute every part of the UI state that can be statically determined, with the hope that the performance will be much better when only the minimal amount of change has to actually occur when the terminal application is running.
Current efforts are being done in a separate branch.
Current drawbacks:
After this is done, if time permits, we should investigate opportunities for parallelization of the few computations that remain on the UI part.
The text was updated successfully, but these errors were encountered: