Skip to content

perf: avoid allocation on Cell::contents #14

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

chris-olszewski
Copy link
Contributor

Avoid allocating an owned String when calling Cell::contents by building up the underlying byte array when Cell::set and Cell::append are called.

Essentially doing the String::push that was happening during Cell::contents, but do it targeting a byte array instead of a vector.

I realize this is a breaking change, but callers can perform the allocation if they need an owned string.

Testing:
Existing test suite passes along with the qc_random_long.

chris-olszewski added a commit to vercel/turborepo that referenced this pull request Mar 6, 2024
### Description

Due to our use case we need to extend `vt100` with some functionality.
The functionality can be added upstream, but based on the age of PRs on
the project, we cannot wait for this to happen.

Reviewing instructions:
I quick documented changes I made from the straight `vt100` crate.
Significant behavior/bug fixes will be added in future PRs

General plans of changes:
- Cherry pick [underflow fix](doy/vt100-rust#11)
 - [Support dimmed formatting](doy/vt100-rust#9)
- Add a version of `Screen` that displays *all* content including lines
that are now in the scrollback
 - Some [perf fixes](doy/vt100-rust#14)

### Testing Instructions

Verified existing test suite passes on my machine. Verify test suite
passes on CI
chris-olszewski added a commit to vercel/turborepo that referenced this pull request Sep 6, 2024
### Description

`ratatui` does a great job of only updating cells that are different
between render, but constructing the `vt100` screen can be intensive.

This PR avoid constructing the screen if there are no updates to the the
app state meaning there's no reason to re-render the TUI.

There are some additional changes we can also make to lower CPU usage
more:
- We're currently spending a lot of time polling for terminal events see
if there's a less resource intensive alternative.
- Patch vt100 so constructing `Screen` is less resource intensive e.g.
doy/vt100-rust#14

### Testing Instructions

Using TUI in [next.js](https://github.com/vercel/next.js)
```
pnpm dev -F next
```

Before
<img width="302" alt="Screenshot 2024-09-06 at 12 40 07 PM"
src="https://github.com/user-attachments/assets/698595a0-f02e-4ef0-8880-ab39a6ecf32c">


After
Ran via `cargo build -p turbo --release` and `turbo_dev --skip-infer dev
-F next`
<img width="292" alt="Screenshot 2024-09-06 at 12 31 00 PM"
src="https://github.com/user-attachments/assets/66859912-7cea-4180-8c5e-10ea32312c52">
@doy
Copy link
Owner

doy commented Jan 11, 2025

merged, thanks!

@doy doy closed this Jan 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants