Ideas for further enhancements

[ms178]

As I already use a x86-64-v3 repository as my baseline, this is already a good start to get a more optimized installation if you have a compatible CPU. If you like you can share your ideas for further enhancements in this thread. Of the top of my head, I came up with the following.

a) Profile-Guided Optimizations (PGO) / BOLT:

• several performance-sensitive packages could profit from the use of PGO (and in addition, BOLT), the hard part is how to get the profiles and integrate it into the makepkg-centric workflow (only very few projects integrate PGO into their build process already), there is a special makepkg addon to integrate PGO but my first two naive tries were unsuccesful to get that to work

• a good first target would be LLVM/Clang, looking at ClangBuiltLinux/tc-build@b8ef75c I wonder how hard it would be to incorporate such a PGO+BOLT workflow in my PKGBUILD - help is very much welcome!

• from experimentation on other distros, I found that PGO for Mesa could also yield some improvements

b) Identify more performance-sensitive packages and find optimization opportunities for them

• my current method is based on trial and error with benchmarking two older Steam games at 1440p with an in-game benchmark (Company of Heroes 2, Tomb Raider). That is not a perfect indicator, as there is some variation, it is the most reliable way to verify the results. I usually compile two to three dozens of additional packages by hand from AUR, the ones which might have a noticeable impact to latency are the ones from KDE/Plasma (which is my destkop environment), some important packages for the graphics stack (Mesa, libdrm, DXVK, vkd3d-proton, libx11, pixman, xorg-server, xf86-video-amdgpu etc.) or that are always running in the background anyway or might have an impact as they might process data or migtht be important for other reasons (e.g. systemd, dbus-broker, libinput, xorg-xinput, sdl2, pipewire/wireplumber, faudio, alsa, openssl, coreutils)

--> it would be great to have a list of known-important packages which have the most performance impact, ideally testing with different compilers and compiler options to identify the optimal configuration, maybe a look at other Arch repositories or distros can give me some hints

[ms178]

I've since added:

• LTO/PGOed binutils
• LTO/PGOed Mesa-git package

I've also tried some experiments with LLVM but only got the original llvm-bolt-script to work, albeit that toolchain has issues with compiling Mesa-git.

[xeome]

do you use discord? or any other communication method you prefer? just for friendship because you seem like a cool person

[ms178]

@xeome I just sporadically use Discord (but I can endorse the CachyOS channel), feel free to discuss ideas over here.

[dsreyes1014]

Are you updating your KDE packages? They seem to be using qt6 now. Not sure how to get past milou-git.

[ms178]

@dsreyes1014 Thanks for showing some interest in the customized KDE packages. Your are right, they are using qt6 now for a week or so. I switched back to using the default packages as that is too unstable for my taste at the moment. But sooner or later I 'd have to update my packages. I am still looking for a more automated way to get there though, as I have done this work manually up until now. You can imagine that with the large amount of packages you that it took me quite some effort to get there and am not too keen to sink too much time into it now during the transition phase.

I'd need to figure out which packages need the new qt6-packages and if they added other new dependancies. Help is welcome.

[ms178]

@dsreyes1014 I've started the progress on manually updating the packages, I cannot commit to a specific time frame for testing. This is totally untested for now and only was mechanical adjustment for qt6 and kf6 (if that even exists yet). For some reason, I cannot change the qca-qt5-git package, but will continue there once I figured out why or if I hit a daily change limit. I have used the Github search function to identify all qt5-base packages; while at it I changed other qt5-subprojects and also upgraded from kf5 to kf6, I also adjusted some other qt5-related packages. I still need to go through these other ones methodically another day to make sure I haven't missed anything.

Testing and MRs are both welcome if you beat me to it. :)

[dsreyes1014]

Following your list to build KDE I couldn't get past milou-git as I'm no developer who understands cmake error messages. I like to tinker and figure things out but not sure where to start. I was able to get some packages to build by updating/adding to PKGBUILD with '-DQT_MAJOR_VERSION=6' as it seemed to be pulling in qt5 and erroring out but the message for milou-git seems to look for KF5KI18n instead of the new KF6KI18n.

[ms178]

@dsreyes1014 Yeah, I am also just an enthusiast user that fiddles around with PKGBUILDS. :D I haven't finished all of the neccessary changes yet. As you see there is more to it than just updating the qt5 > qt6 packages. Also the KDE Framework 5 (KF5) needs to be updated to KDE Framework 6 (KF6) which is spread out all over the place and even in the git checkout section. As you see, it is quite a lot of work albeit mechanical and repetitive in nature.

I am stll looking for a search and replace function that also tackles various sub-directories.

[dsreyes1014]

Yea it is. Really wanted to try kwinft-git to see how far along it has gotten. Kwin stable package feels a little buggy to me (which I can deal with) but I don't want to go back to gnome. :(

[ms178]

I see, I can't stand Gnome either. Due to all this code churn I'd recommend to use the stock KDE packages for the next couple of months until the git-packages get more stable. There are potentially more bugs than usual right now.

I've tried KwinFT-git last week and it compiled fine with GCC. The problem with KwinFT is that I cannot use Clang + my PGO profiles with it; there seems to be a problem with Clang and my CFLAGS in general and KwinFT wheras the PGOed Kwin ran pretty well.

[dsreyes1014]

I can never get kwinft-git to build for some reason. I'll have to try again and see if it'll build at least with some of the stable packages.

[ms178]

@dsreyes1014 Are you sure that you have all dependancies installed? Try paru or yay that handle the dependancy chain correctly. Hoewever it is possible that some of these cannot be build due to the qt6-transition, e.g. kcoreaddons-git is needed but might need qt6 itself.

[dsreyes1014]

I've been using paru for awhile now so yea but I've never been able to build it for some reason or another. I understand if you can't answer but what's your process of building KDE with kwinft? Like how are we testing everything is built in order and behaving correctly? I'd like to maybe dig a little and see how to get closer to a usable desktop using the git packages. If I can help in any way, with the little bit of time I have, I will.

[ms178]

By the way, I found a way for automatic search and replace of certain strings, from the KDE main directory: grep -rl 'qt5-base' ./ | xargs sed -i 's/qt5-base/qt6-base/g'

[ms178]

By the way, I just replaced the KDE directory with new files which replaced all terms I knew of. But kwinft and the other subprojects needed are probably broken right now.

To your question of building kwinft - I usually start with extra-cmake-modules-git, ki18n-git, kcoreaddons-git, kdecoration-git, seatd-git, wlroots-git, wrapland-git, disman-git, kdisplay-git and then kwinft-git. I hope I haven't forgotten anything.

[dsreyes1014]

It seems after the changing things in KDE with the grep command still won't allow things to configure. I still need to add '-DQT_MAJOR_VERSION=6' in the PKGBBUILD for let's for example ki18n-git.

[ms178]

Hm, perfectly possible that there are more changes needed. To be honest, I lack the motivation to tackle all of these right now as I'd rather stay on the stable packages for a few more weeks.

[dsreyes1014]

No worries at all. Thanks for looking into it.

[ms178]

@dsreyes1014 I've done some work on this lately, but the KDE-git packages are untested and I would strongly advise not to use them. However, I also uploaded the KDE-stable variant which I've tested myself and works fine.