Skip to content
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

perf: increase rendering efficiency #1017

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

JustLinuxUser
Copy link
Contributor

Type of Change

  • New feature
  • Bug fix
  • Documentation update
  • Refactoring
  • Hotfix
  • Security patch
  • UI/UX improvement

Description

This small PR, makes, so that the UI is not re-rendered, unless an event is detected. The event might be a terminal event (keypress, mouse moved, resize, etc.)
Or if a terminal is open, if some new input came in from the terminal

Testing

Before: 50% CPU usage on my machine with debug on
After: 1% CPU usage on my machine with debug on

Impact

It doesn't impact the performance of the app, it will run just as fast as before, but it affects it's efficiency, so it's not re-rendered unless it should be.

Additional Information

I am not aware of any possible side effects this might create, but if in the future we want to implement something like an animation system, it will complicate it a little.

@adamperkowski adamperkowski changed the title Increase the efficiency of rendering perf: increase rendering efficiency Feb 7, 2025
@adamperkowski adamperkowski added refactor rust Pull requests that update Rust code labels Feb 7, 2025
Copy link
Collaborator

@adamperkowski adamperkowski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure i'm 100% with you on using atomic but still the improvement is huge. thanks!

@JustLinuxUser
Copy link
Contributor Author

JustLinuxUser commented Feb 8, 2025

not sure i'm 100% with you on using atomic but still the improvement is huge. thanks!

I used an atomic, because:

  1. It's accessed from a different thread,
  2. It's basically free on x86,
  3. if it's a global, we can later rename it to SHOULD_REDRAW, and use it when ever needed.

But I would like to know why you don't like the usage of the global atomic. Mb there is a better solution that I am not seeing?. Ty

@adamperkowski
Copy link
Collaborator

But I would like to know why you don't like the usage of the global atomic. Mb there is a better solution that I am not seeing?. Ty

not saying i don't like it being there. it's more about when i see atomic i'm like:

  • cache issues
  • memory ordering
  • synchronization costs
  • damn deadlocks again
  • we have alternatives, higher level abstractions in rust

+ it might be a little bit overkill
but still, the effects are very much positive and that's what matters :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactor rust Pull requests that update Rust code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants