0.11.0 seems to be slower than 0.10.2 on Ubuntu

Checklist

I've looked through the troubleshooting docs, the known problems list, and existing open issues for similar issues.

What operating system and version are you using?

Ubuntu 20.04 & 22.04

What architecture are you using?

x86_64/AMD64

What terminal(s) are you running bottom on that are experiencing the problem?

Wezterm 20240204-094054-a0974a25

(Optional) What filesystem(s) are you using?

No response

What version of bottom are you running?

0.11.0

How did you install bottom?

Installed by downloading prebuilt binary from GitHub.

Describe the issue

Version 0.11.0 of bottom exhibits significantly higher latency compared to version 0.10.2 when displaying the initial statistics, on Ubuntu but not Windows 11 though.

Testing Method:

Launch btm and immediately exit upon the appearance of the statistics.
Measure the elapsed time using $env.CMD_DURATION_MS in Nushell. Acknowledging this is not a precise benchmark, but relative differences are notable.

Results:
• 0.10.2: ~2447 ms
• 0.11.0: ~12344 ms

What is the expected behaviour?

The latency should be similar.

What is the actual behaviour?

Statistics takes a long time to show up.

How can we reproduce this?

Launch bottom and profile the time it takes for the initial statistics to show up.

Additional information

No response

Hmm... not sure why this is the case, maybe there's extra work being done due to the stuff like GPU? Actually, if you run btm --disable_gpu, does it change anything?

I'll look into it though and see if I can replicate on my Linux machine.

Hmm... I can't replicate this on either zsh or nu, but I can take a look and see if I can make it so things don't block as much/there's a timeout (#687 might be related).

Also just double checking, which binary did you download?

@ClementTsang

@ClementTsang Thanks for the response.

Using --enable_gpu on v0.10.2 and --disable_gpu on v0.11.0 makes neglectable differences:

Version	w/ GPU (ms)	w/o GPU (ms)
0.10.2	1358	1258
0.11.2	12402	11357

I'm using the bottom_x86_64-unknown-linux-<c>.tar.gz where <c> is gnu and musl (I've tested both).

Thanks for the info, at least that narrows some things down.

Hmm... I can't replicate this on either zsh or nu, but I can take a look and see if I can make it so things don't block as much/there's a timeout (#687 might be related).

Which part of the source code is related to the timeout mechanism?

There isn't any at the moment... it's all synchronous code, data collection runs on a separate thread.

It's unlikely tbh that I can actually add a timeout (barring going into async but that's a very hmmm choice for this is my gut feeling) I can explore threading things more though.

Though it seems counterintuitive to me, the new version runs well on Windows 11.

@ClementTsang

@ClementTsang Thanks for your work on v0.11.1, but the startup is still slow. Is there a way I can debug on my machine?

Barring making code changes like debug logs, not really. I could compile a binary here with debug logs I guess.

Could you also give me some info on system specs? e.g. GPU, CPU, etc?

Also tested it on wezterm on my Linux machine and there's no difference, so it isn't that.

Could you also give me some info on system specs? e.g. GPU, CPU, etc?

Windows 11: AMD Ryzen 5 5500 + GeForce RTX 4060
Ubuntu 20.04: AMD EPYC 7502 32 Core + GeForce RTX 3090 * 2
Ubuntu 22.04: AMD EPYC 7T83 64 Core + GeForce RTX 4090 * 7

Is there a way I can debug on my machine?

With --disable_gpu you could try changing the layout rows in the bottom config to use only a single widget at a time; to isolate if any are slow. Is the empty widget by itself slow? Does basic mode UI load slowly too? The used_widget/widgets_to_harvest checks should avoid some collections/drawing...

It is still slow even I use the basic mode and only one column for the processes widget. With 0.10.2, the latency is short even I use the full mode.

It is still slow even I use the basic mode and only one column for the processes widget.

I was refering to the the layout only using a single widget so the others will not be drawn/collected in full mode at all incase one is unusually slow. Just changing the active columns does not do this afaik. Something like the following at the bottom of the toml config (change type to proc/cpu/mem/net/temp/disk):

[[row]]
#  ratio=30
#  [[row.child]]
#    type="net"
  [[row.child]]
    type="empty"

Thanks for the good information on basic mode still being slow... (There was a refactor around points/graph UI)

With 0.10.2, the latency is short even I use the full mode.

Which is odd as they both collect and display mostly the same information. That suggests collections may not be the slow part; that something has changed for all widgets or a specific one has found a bad pathological case. If the latency persists with little to no widgets/collections (ie empty) then that suggests a more endemic issue like a library.

If possible could you record an example of the behaviour? Anything might help when we can't locally reproduce it.

And yes thanks for trying out various widgets - just to check, have you tried with the process widget disabled as well?

@jamartin9

@jamartin9 Thanks for the clarification.

It seems that the bottleneck lies in the process widget. All other widgets display the statistics almost immediately on startup. I record an example of using the process widget only:

btm-0.11-1.mp4

Thanks! That narrows down things a lot.

Could you also give me some info on system specs? e.g. GPU, CPU, etc?

Windows 11: AMD Ryzen 5 5500 + GeForce RTX 4060

Ubuntu 20.04: AMD EPYC 7502 32 Core + GeForce RTX 3090 * 2

Ubuntu 22.04: AMD EPYC 7T83 64 Core + GeForce RTX 4090 * 7

Updates about 0.11.2:

It now costs about 5 seconds on the Ubuntu 20.04 machine and still 11 seconds on the Ubuntu 22.04.
It immediately shows the proc widget on an openEuler 22.03 machine!

Currently this behavior only happens on the Ubuntu 20.04 machine and the delay shortens from 11 seconds to about 3 seconds. Another machine with the same CPU and GPUs, but with Ubuntu 24.04 and much bigger RAMs, does not have this issue. I wonder if it is OS related.

It can be closed if you want. Thanks for all the efforts.

Thanks for the update - I can keep it open for now as this is still pretty interesting to me, and it's a good motivator to look for possible slowdowns/speed up the data collection step anyway.

Navigation Menu

Repository navigation

0.11.0 seems to be slower than 0.10.2 on Ubuntu #1777

Checklist

What operating system and version are you using?

What architecture are you using?

What terminal(s) are you running bottom on that are experiencing the problem?

(Optional) What filesystem(s) are you using?

What version of bottom are you running?

How did you install bottom?

Describe the issue

What is the expected behaviour?

What is the actual behaviour?

How can we reproduce this?

Additional information

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

0.11.0 seems to be slower than 0.10.2 on Ubuntu #1777

Description

Checklist

What operating system and version are you using?

What architecture are you using?

What terminal(s) are you running bottom on that are experiencing the problem?

(Optional) What filesystem(s) are you using?

What version of bottom are you running?

How did you install bottom?

Describe the issue

What is the expected behaviour?

What is the actual behaviour?

How can we reproduce this?

Additional information

Activity

ClementTsang commented on Aug 11, 2025

ClementTsang commented on Aug 11, 2025

ClementTsang commented on Aug 11, 2025

neur1n commented on Aug 12, 2025

ClementTsang commented on Aug 12, 2025

neur1n commented on Aug 12, 2025

ClementTsang commented on Aug 12, 2025

neur1n commented on Aug 12, 2025

neur1n commented on Aug 15, 2025

ClementTsang commented on Aug 15, 2025

ClementTsang commented on Aug 15, 2025

ClementTsang commented on Aug 15, 2025

neur1n commented on Aug 15, 2025

jamartin9 commented on Aug 15, 2025

neur1n commented on Aug 16, 2025

jamartin9 commented on Aug 16, 2025

ClementTsang commented on Aug 16, 2025

ClementTsang commented on Aug 16, 2025

neur1n commented on Aug 17, 2025

ClementTsang commented on Aug 17, 2025

neur1n commented on Oct 29, 2025

neur1n commented on Dec 19, 2025

ClementTsang commented on Dec 19, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions