Open PTomalak opened 9 months ago
Which aur are you using?
Which aur are you using?
I tried newest versions of both vscodium-bin
and vscodium
(using yay), both shared the same long startup delay.
For looking up the performance of the older versions I used modified PKGBUILD of vscodium-bin
Came here to say that I encounter the same behavior with Arch+Gnome+Wayland.
After the latest update, both native Wayland and XWayland versions display slow startup ( more than 10 sec, while before it loaded instantaneously).
I also have this error in journalctl -b
at every startup:
gnome-shell[1148]: value "nan" of type 'gfloat' is invalid or out of range for property 'width' of type 'gfloat'
gnome-shell[1148]: value "nan" of type 'gfloat' is invalid or out of range for property 'width' of type 'gfloat'
same here on both of aur and flatpak
Same here, was hoping latest version would fix it, but no. VSCode proper does not have the same issue.
I am on Windows 10, using the "portable" version of VSCodium, without any nasty installers.
Also experiencing this issue on Arch & Wayland
Also facing this issue. Its happening to all electron based softwares( like obsidian)
removing nvidia-utils
package fixed this problem for me
I have an interesting update that seem to be related to the issue. I was facing problems when using vulkan and wgpu:
loader_scanned_icd_add: Could not get 'vkCreateInstance' via 'vk_icdGetInstanceProcAddr' for ICD libGLX_nvidia.so.0
Any wgpu program I tried to run would start with a significant delay and throw aforementioned errors.
which thanks to this post: If you have multiple GPU or accidentally installed 2 drivers, ...
probed me to make sure I am not using any NVIDIA related dependencies on my Intel iGPU laptop
after uninstalling sudo pacman -R opencl-nvidia nvidia-utils
and updating vscodium-bin
to latest release (as of now vscodium-bin 1.91.1.24193-1
) it now opens almost instantaneously, just like it used to on versions prior to 1.86.2.24053
(I was surprised to learn nvidia-utils
was even installed on my system, it must have came as a dependency to one of the packages I installed in the past)
Please see if following similar steps fixes the issue and comment, so that this issue can be closed!
Also experiencing this issue on Arch & Wayland
It might also be another issue: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10257
I am seeing a lots of ioctl(/dev/dri/renderD129, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7fffbfd6b990) = -1
originating from /usr/lib/dri/iris_dri.so
when launching VSCodium in wayland native mode. I need to wait at least 2~4 minutes before the VSCodium window show up. I am using a laptop with intel and nvidia graphics.
I've also been having this issue, I've tried every AUR package, and they're all the same, many minutes to open if at all.
I have an Intel Arc A380 as my primary GPU and output, and an Nvidia RTX 3090 as my secondary GPU with no output, using prime offloading for individual programs and games, but not for my Wayland compositor (Hyprland)
EDIT: I also weirdly found that in Wayland mode the secondary sidebar does not work, I can't drag to it, and if something was dragged to it in X11 mode it will be empty in Wayland mode. I just switched to X11 (Xwayland) and it starts instantly and works without issue.
https://bbs.archlinux.org/viewtopic.php?id=298254
This fixed my error
At some point between 1.85.2.24019 and 1.86.2.24053 vscodium got abnormally slow to startup
To Reproduce
1.85.2.24019
or below and runtime vscodium --verbose --disable-extensions
, CTRL-C when window loaded1.86.2.24053
or above and runtime vscodium --verbose --disable-extensions
, CTRL-C when window loadedExpected behavior A clear and concise description of what you expected to happen.
Screenshots If applicable, add screenshots to help explain your problem.
Desktop environment:
Additional context The startup times from past recent versions: (accurate to +/- 1 second as manually stopped with CTRL+C when everything loads)
logs from
1.87.0
logs from
1.85.0
Any idea what might have caused it, how to diagnose it further? Is it specific to my setup or was something introduced across those versions that slows down the startup?