wez / wezterm

A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust
https://wezfurlong.org/wezterm/
Other
16.74k stars 750 forks source link

Improve resources consumption #4750

Closed HumanG33k closed 7 months ago

HumanG33k commented 8 months ago

What Operating System(s) are you seeing this problem on?

Linux X11

Which Wayland compositor or X11 Window manager(s) are you using?

I3 on debian testing

WezTerm version

20231221-214626-84ae00c8

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

No, and I'll explain why below

Describe the bug

I currently use a "weak" 16Go of ram computer.

If i use wezterm (as i use terminal for everything) the menory use is jast make my computer useless. If htop is right most of wezterm-gui process use near than 4 % of ram each.

II ready to make some tests/benchmark whatever. Just make me a tutorial. (even if i need to compile something)

I want to improve the stable version, if some correction will be done how fast they will be release ? to know when retry.

To Reproduce

No response

Configuration

no config

Expected Behavior

No response

Logs

Some of logs :

23:53:19.804 INFO wezterm_gui > Spawned your command via the existing GUI instance. Use wezterm start --always-new-process if you do not want this behavior. Result=SpawnResponse { tab_id: 23, pane_id: 23, window_id: 23, size: TerminalSize { rows: 24, cols: 80, pixel_width: 640, pixel_height: 384, dpi: 0 }} ()

23:07:20.306 ERROR termwiz::escape::parser > impossible C0/C1 control code '\u{81}' 0x81 was dropped 23:07:20.371 WARN wezterm_term::terminalstate::performer > ST never received for pending tmux title escape sequence: "" 23:07:20.371 WARN wezterm_term::terminalstate::performer > ST never received for pending tmux title escape sequence: "+k" 23:07:20.371 WARN weztermterm::terminalstate::performer > ST never received for pending tmux title escape sequence: "k�of\u{7f}\u{7f}" 23:07:20.375 WARN wezterm_term::terminalstate::performer > ST never received for pending tmux title escape sequence: "TBLT2" 23:07:20.381 WARN wezterm_term::terminalstate::performer > ST never received for pending tmux title escape sequence: "ҩ��/" 23:07:20.382 ERROR wezterm_term::terminalstate::sixel > Ignoring image with 0x0 dimensions 23:07:20.382 ERROR termwiz::escape::parser > impossible C0/C1 control code '\u{80}' 0x80 was dropped

22:28:07.755 WARN window::os::x11::connection > Unable to resolve appearance using xdg-desktop-portal: get_appearance.read_setting: Reading xdg-portal org.freedesktop.appearance color-scheme: I/O error: Timed out reading from xdg-portal; this indicates a problem with your graphical environment. Consider running 'systemctl restart --user xdg-desktop-portal.service': Timed out reading from xdg-portal; this indicates a problem with your graphical environment. Consider running 'systemctl restart --user xdg-desktop-portal.service'

Anything else?

I didn't use systemd

wez commented 8 months ago

4% doesn't sound bad at all. I suspect something else is the problem, but there isn't enough information here about what you're trying and what you're experiencing. There is nothing that we can do to help you without more information.

HumanG33k commented 8 months ago

What information do you need. 4% each with nothing running inside look a little to much for me as it. my uxterm are more near than 0.1%. when you run more than 10 terms by workspace (currently 10) it can be an issue quite fast.

Only process than use more mem on my computer is my more 2k open firefox and my thunderbird.

As I already says i m ready to had more information make tests you need or whatever. Tell me what do you need.

wez commented 8 months ago

I need time that I don't have. It's time consuming to go into profiling mode, and as I said, I don't consider the current utilization to be a problem. I have no incentive or desire to look at this. If you are really committed to making this better, then you will educate yourself on what to look at, profile, analyze the code and come back with detailed and actionable findings.

github-actions[bot] commented 7 months ago

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

github-actions[bot] commented 6 months ago

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.