OS troubles and performances

Introduction

In the past couple of years, I have been growing more and more unhappy about working with windows, specifically, poor performance: Long compile times, hot CPUs, throttled GPUs due to heat, low FPS in games... while this is partialy due to the notebook producer choices, I feel like the OS is not helping here. What I've observed in the past are fairly long compile times, as well as slow git operations. When researching the symptoms, one of the reasons that was often cited was the antivirus and filesystem overhead on Windows.

I recently got a new laptop, so I decided to give Linux a try. Since the PC uses a brand new AMD CPU and GPU, I had a bit of trouble with getting a Linux distribution to work properly. I ended up installing Bazzite, as it was suggested by others to work well on this hardware.

The notebook I use is a GPD Duo - a pretty weird looking notebook that has two displays. Both displays are touchscreens and have stylus support (which I find pretty amazing). The bottom screen is installed upside down, which requires the OS to flip the output - which causes quite a few problems. For example, the stylus position is flipped. And the second screen's touch and stylus input is mapped on the primary screen on Linux. I haven't found a way to fix this yet.

On windows, this all works out of the box.

The GPD Duo notebook - two screens for twice the fun

Tools and workflows

In my private time, I mainly use these tools:

Visual Studio Code
Git
gcc for compiling C programs, mostly raylib
Lua
Blender

I don't really game much, so this is a secondary concern for me.

Surprisingly, working on the blog has become my main activity. For this blog, my Lua scripts would originally simply generate the HTML. The site log describes this process a little bit.

But I keep adding more and more features to the blog.

For example, last November, I had the idea to compile WASM content directly from within the blog scripts. Building and embedding a raylib program into the blog looks like this:

CFile(
  {"td-tut-47/td_main.c", "td-tut-46/td_main.c"},
  {"td-tut-47/td_main.h:150", "td-tut-46/td_main.h", highlight=true},
  {"td-tut-47/enemy.c:23", "td-tut-46/enemy.c", selected = true, highlight=true},
  {"td-tut-47/tower_system.c:10", "td-tut-46/tower_system.c"},
  "td-tut-47/path_finding.c",
  "td-tut-47/projectile_system.c",
  "td-tut-47/particle_system.c",
  "td-tut-47/preferred_size.c", "td-tut-47/preferred_size.h")
P[[
Click "Begin waves" to see the enemy spawning as orcs:
]]
WASM("td-tut-47/td_main.js", 600, 400, "td_tut_47_td_main", false, true)

The CFile function produces the HTML for displaying the source code on the blog, but it also compiles the C files into WASM. The WASM function embeds the HTML needed to render the WASM content into the blog.

To minimze manual steps, I wrote a small webserver in C that serves the blog content during development, triggering new builds when the source files changed. This way, I can see the changes in the blog immediately after saving the source file and refreshing the browser.

The website generation and compilation has become a pain point for me, and it turns out, that the OS has a big impact on the performance of this workflow.

Workflow performance

Compiling a single tutorial example like the one given above took around 40-60s on my old Windows laptop.

This is long enough that doing smaller changes for testing becomes quite painful. Git operations are also slow, but I don't use these so frequently.

On my new machine, I wanted to see how much faster this would be using Linux.

Experiences

Without going into detail, what I found out was, that the compilation time of the emscripten projects was about 10 times faster compared to my old notebook on Windows. I also kinda liked the UI and feeling of the OS. But my old notebook is also a few years older, so it's not a fair comparison.

The longer I worked with Linux, the more it reminded me of my old experiences when I tried Linux desktops around 2010: Lots of interesting new things, but a lot of small and big things that don't quite work as expected: as mentioned, I couldn't figure out how to fix the stylus and touch input. The 2nd screen would randomly fail and couldn't be turned on again. I assume the random OS freezes might be related and both is probably due to the hardware drivers not being fully compatible with the Linux kernel.

The battery lifetime however seems better than on Windows. Maybe because the CPU load stayed lower most of the time.

Getting my blog software running was mostly not a problem, but the C webserver I wrote was of course running on Windows only, so I had to add the Linux support for it - which didn't take much time. When compiling the emscripten projects, it took like 3-5s in average, which is a huge improvement over the 40-60s on Windows and felt good. The blog build times, which involves a lot of IO operations, is also quite a bit faster, often taking less than a second.

However, when I tried to compile a raylib project for desktop, I ran into a lot of problems of which some I don't know how to resolve: The linker would need the GL library, but when I try to install a GL devel package, the manager can't install it because of unmet dependencies - something I dreadfully remember from my past Linux experiences. For me, that feels like a dead end, as I really don't know how to resolve this and documentation on this tends to be sparse.

So I am retrying to find out if I can get the same performance on Windows.

WSL

I've heard about WSL before, but when I tried it, it didn't turn out to run so different - which is why I didn't try it again. But I wanted to give it another shot. My first try didn't look good. Opening a page in the browser that triggers relevant page rebuild would take around 10s - a quite terrible experience.

But then I had the idea to check out the project in the WSL filesystem and see how it performans there. And that did the trick: Instead of 10s, the very same page would now get built in 0.1s. Yes, a hundred times faster. I have no idea why this is the case - when running the same script in MinGW, it would take around 1s to 2s in average. Not great, but OK.

Another difference is the compile time for the emscripten projects - here's a screenshot of the comparison for the same kind of change that gets recompiled:

Comparison of compile times between WSL and MinGW (also note the nice handwriting I can do with the stylus on the GPD Duo :D )

This shows that the new laptop takes about 20s for the recompile - which on my older laptop took around 40-60s. The WSL compile time is however only around 4s to 5s - so around 4 times faster than the native Windows compile time and quite similar to the build times on Linux.

I find this difference really astonishing. My guess is that the windows filesystem access is the bottleneck here, though I don't know why. Disabling the antivirus seems to reduce the emscripten build time from 20s to 10s, and the blog build time is improved in a similar way. It is still somewhat slower, but it shows that antivirus setting has a big impact on the performance.

Conclusion

I didn't run a lot of tests, so this needs to be taken with a grain of salt. What I can say for sure is that the performance of my typical tasks worked smoother and faster on Linux. The downside was the hardware compatibility and configuration issues. But the most severe problem for me was that I can't figure out how to resolve package dependency issues. I remember that I spent countless hours on this in the past without success - and I don't want to do this again.

On the upside, I discovered that WSL seems to work really well, if the windows filesystem is avoided. The good thing about trying out Linux was that the changes I made to the blog software to support Linux also made it work on WSL.

So I guess I will stick to Windows + WSL for now. Since the build times are now acceptable, I don't have a strong reason to switch to Linux. Besides, I can use the full potential of the screens and the stylus on Windows, which is a big plus for me.

It's really a bit sad, as I would have liked to switch to Linux for a while now. But I guess I will take here the path of least resistance, since I don't want to spend most of my free time on fixing OS issues.