Take a look at the requirements.txt: https://github.com/qtile/qtile/blob/ecf216205ccfe72bbdee3183...

All the heavy lifting is offloaded to C libraries. So, no, you shouldn't see a significant performance penalty, unless your Python WM is doing bitcoin mining in the background or something.

It's a WM (Window Manager). It only sets the placement of windows, it does not interfere with the programs themselves (that's what systemd and gnome-session do) nor does it do the fancy part of the painting (that's what a compositor does).

So no, do not expect a significant performance penalty.

Having done tiling WM with lots of logic implemented in Lua myself, ten or so years ago, I never met any performance issues, besides repainting of dragging indicators for free floating windows

Couldn't really imagine there being any. WM events are few and far between, and are hardly constrained by single thread performance.

Curious how the garbage collector works.

I used a Go-based window manager called Wingo for quite a while and never noticed any performance issues.

Go is also fully compiled to native code, big difference.

But it's still garbage collected. And GC should be done by the python interpreter proper, so it would be in native code.

A tiny portion of Python's total execution time.

Don't get me wrong; I expect Go to be far more performant than Python. Just, they're both garbage-collected, and I have no reason to expect GC perf (specifically) to differ.

Which just shows that learning about GC algorithms is a must.

http://gchandbook.org/

And the differences between value types, AOT compiled code execution, bytecode interpreters and FFI marshalling costs between bytecode interpreters and native libraries.