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
Currently we have only extremely focused benchmarks. dense_cells tests a scenario where every single cell takes a huge escape sequence, while light_cells tests for scenarios where pretty much no escape sequences are present.
When it comes to improving performance with something like alacritty/alacritty#8347, it's not always possible to improve every individual component of the parser. Since the "medium workload" in between dense_cells and light_cells is likely the best representation of what users would encounter in the real world, it should make sense to add this extra benchmark as a hint at real-world performance.
Generally speaking this is likely best simulated by an escape sequence heavy application, that doesn't just focus on generating graphical effects (like mpv -vo tct). The best choice that comes to my mind would be vim with a workflow that includes both local edits, complete buffer jumps, and popups like fuzzy finders.
The text was updated successfully, but these errors were encountered:
This patch adds a new benchmark which aims at filling a gap between the
`dense_cells` and the `light_cells` benchmarks, providing a more
realistic example of escape sequence density in a normal terminal
workflow.
The new benchmark is an Alacritty ref test recording of a short NeoVim
session, which includes several small and large buffer movements,
different styles of underlines, and window-in-window using a fuzzy
finder and tiled buffers.
This new test intentionally uses a workflow that is pretty escape
sequence heavy, while still being realistic, since workflows without
heavy escape sequence use are already reasonably well covered by the
`light_cells` benchmark.
Closesalacritty#40.
Currently we have only extremely focused benchmarks.
dense_cells
tests a scenario where every single cell takes a huge escape sequence, whilelight_cells
tests for scenarios where pretty much no escape sequences are present.When it comes to improving performance with something like alacritty/alacritty#8347, it's not always possible to improve every individual component of the parser. Since the "medium workload" in between
dense_cells
andlight_cells
is likely the best representation of what users would encounter in the real world, it should make sense to add this extra benchmark as a hint at real-world performance.Generally speaking this is likely best simulated by an escape sequence heavy application, that doesn't just focus on generating graphical effects (like
mpv -vo tct
). The best choice that comes to my mind would be vim with a workflow that includes both local edits, complete buffer jumps, and popups like fuzzy finders.The text was updated successfully, but these errors were encountered: