High CPU usage when VPN is disconnected and killswitch is on (on Linux)
Steps to reproduce
Reopening #9887. I think that this is a separate issue from #8086, because the VPN killswitch issue
- Reproduces even when all animations are disabled
- Does not reproduce if Telegram is merely run with internet disconnected
- Burns CPU time in QNetworkAccessManager rather than QWidgetRepaintManager
I collected two perf recordings, using Mullvad: this one is with the killswitch enabled and this one is without an internet connection but with the killswitch disabled. Please let me know if any additional data would be helpful.
Expected behaviour
Should not use more CPU with a VPN killswitch enabled compared to with no internet connection.
Actual behaviour
Uses more CPU with a VPN killswitch enabled compared to with no internet connection.
Operating system
NixOS 25.11 (Xantusia) aarch64, using Hyprland 0.52.1 (Wayland)
Version of Telegram Desktop
6.2.3 (as packaged by NixOS)
Installation source
Other (unofficial) source
Crash ID
No response
Logs
How can I open your recordings?
@ilya-fedin okay, I have a better idea: here is a flamegraph for normal operation without internet or a killswitch, and here is a flamegraph for operation with a killswitch.
Can you reproduce with static binary, flatpak package or snap package? The graphs point like most time is spent in the library not even used in official builds.
Can you reproduce with static binary, flatpak package or snap package? The graphs point like most time is spent in the library not even used in official builds.
Unfortunately I can't run an official build until you fix #24564. Which library is not used in official builds? I can try reporting this to nixpkgs and looping in the maintainers there who could probably compare the behavior to official builds.
Unfortunately I can't run an official build until you fix #24564.
Can you check whether it's still actual?
Which library is not used in official builds?
Qt is built without libproxy. It's also patched to use portal proxy resolver though...
Unfortunately I can't run an official build until you fix #24564.
Can you check whether it's still actual?
Which library is not used in official builds?
Qt is built without libproxy. It's also patched to use portal proxy resolver though...
You're right, I was able to run the Flatpak version. This version actually had even worse CPU usage. Here is the flamegraph with and without the killswitch enabled.
To be precise, I obtained this by logging into Telegram, then doing mullvad connect (or disconnecting for the control sample), then disconnecting from WiFi, then running
perf record --call-graph "dwarf" flatpak -- run org.telegram.desktop
and leaving the window running for 20 seconds before closing it. Additionally, I warmed up the cache before doing the experiments.
This flamegraph looks weird, like xdg-dbus-proxy is captured instead of tdesktop
This page seem to have an example of how to use perf with flatpak the right way: https://docs.flatpak.org/en/latest/debugging.html#using-other-debugging-tools. On the beginning of the page there are also instructions how to install debug symbols.
This page seem to have an example of how to use perf with flatpak the right way: https://docs.flatpak.org/en/latest/debugging.html#using-other-debugging-tools. On the beginning of the page there are also instructions how to install debug symbols.
Thanks for helping to walk me through this, I am very inexperienced using Flatpak. I installed the debug packages and repeated the experiment with
flatpak run --command=perf --filesystem=/sys --filesystem=$(pwd) --devel org.telegram.desktop record -g -- Telegram
and the results are: with killswitch and without killswitch.
As you can see, I couldn't get debug symbols to work inside Flatpak despite following the instructions you linked. However, the raw offsets are given in the recordings: with killswitch and without killswitch. See man perf-report to see how to analyze the recordings---a good start might be to use perf report -g -i perf.data and interactively explore the callstack.
Let me know if you have any questions or suggestions to enable debug symbols. Note that avalanche are my performance cores and blizzard are my efficiency cores.
Output of flatpak info org.telegram.desktop.Debug so that you can match offsets to the right symbol table:
ID: org.telegram.desktop.Debug
Ref: runtime/org.telegram.desktop.Debug/aarch64/stable
Arch: aarch64
Branch: stable
Origin: flathub
Collection: org.flathub.Stable
Installation: system
Installed: 622.9 MB
Commit: 0e17b3a258a927481f7d7e438116ec918ce67a56847399ad2efefbf9891799ad
Parent: e3db1a8a96996056d9969e216502d4fd56e506fafcd5c30fe3679a2411157931
Subject: Revert "Build Qt without copy_file_range support" (641a325a5e16)
Date: 2025-11-22 17:18:29 +0000
I've remembered you can just switch from system proxy to no proxy in settings and libproxy should be no more queried by Qt. Try to record from your distro package but with no proxy set in tdesktop.
+1 Can reproduce with MullvadVPN + Telegram (installed via Flatpak). When VPN connection drops and the VPN tries to reconnect, the app will have extremely high CPU usage until the VPN is connected.
Linux Mint 22.2 Cinnamon, Telegram 6.3.4 installed via official flatpak repo.
@ilya-fedin (I'm not sure It's possible for me to participate in this bug report) Personally testing, switching from system proxy to no proxy gains a jump from around 20-40% CPU usage to around 80-90% (nearly doubling the CPU usage) For testing, I could provide you (or any of the devs) with my Mullvad account number (See here for more details)
I wait for answer on https://github.com/telegramdesktop/tdesktop/issues/30042#issuecomment-3584129440. Particularly the second part of the message.
Sorry for the late reply. I went to Settings -> Advanced -> Connection type and selected "Disable proxy." Here are the flamegraphs with and without the killswitch enabled.
@ilya-fedin do you need any additional information?
There seem to be just no one interested in working on that. Personally I have no expertise in the relevant code.
If you could provide steps to reproduce on Windows, chance that someone pick up this issue will be much higher.