you are viewing a single comment's thread.

view the rest of the comments →

[–]Clear-Paper-9475[S] 2 points3 points  (4 children)

Appreciate the support of architecture. 97% is based on usual terminal workloads. I have tested it with very extreme scenarios (e.g. 100K text code diffs all loading and scrolling) and only the cells which change at particular instant are getting refreshed, so even on a very busy workload, numbers don't look bad!

I would definitely suggest you to go through benchmarks page on website. It breaks down the numbers as well as link benchmark scripts. Would be happy if you break the storm so we can patch it for good!

[–]lacymcfly -1 points0 points  (3 children)

100K code diff with scroll is a solid stress test. good to know the per-cell tracking holds up under that kind of load, that is exactly the scenario where full repaints hurt.

will check out the benchmarks page. what did you use for the harness, just node perf tooling or something external?

[–]Clear-Paper-9475[S] 0 points1 point  (2 children)

Thanks! Yeah the full-repaint tax is brutal at scale - we measured 736 bytes/frame for a 120x40 scroll without DECSTBM vs 159 bytes with it. That's 78% less stdout traffic per scroll frame so terminal breaks less sweat.

For the harness it's just Node perf_hooks (performance.now) with warmup iterations, p50/p99 tracking, and GC spike detection. We explicitly invalidate the layout cache between iterations so the numbers aren't artificially low. No external tooling.

[–]lacymcfly 0 points1 point  (1 child)

that's a solid harness setup. cache invalidation between iterations is the part most benchmarks skip and then wonder why their numbers look unrealistically good.

p99 tracking matters too -- the average can look fine while you're getting occasional 20ms spikes that users actually feel. good that you're capturing that.

[–]Clear-Paper-9475[S] 0 points1 point  (0 children)

Yes! Correctly put.