Most video games compress booleans to bitfields in the save files to save space. Depending on the game, a save file can contain thousands of objects, so it makes sense to keep it small.
At runtime, booleans are 1 byte each. The additional work of shifting and masking to get to the bit you want simply isn't worth it. When reading from memory, the CPU will read a whole cache lines of 64 bytes anyways. So unless you want to process a lot of booleans (and only booleans) at once, it's simply not worth having them 1 bit each.
Because aligned data runs faster, a single boolean sandwiched inbetween integers or pointers can even take up 4 or 8 bytes of memory.
Note: Some languages have built-in optimisations where an array of booleans is actually 1 bit each. C++'s `std::vector<bool>` is such a case and I'm sure there are more.
I've seen people advise to never use booleans, simply because a number (or enum) can convey more meaning while taking up the same amount of space.
In order to answer this question it is important to understand the fundamental difference between XMPP and Matrix.
XMPP was invented at a time, where communicating online meant sending a message from one device to another.
However, the modern expectations for messaging apps are much more than that. Sending media, using multiple devices, deleting messages, editing messages, read receipts, notifications when typing, group chats, threads, and even managing communities are all things a modern messenger app should be able to do.
The fundamental operating principle has shifted from mere message passing to synchronising a common state between all participants. If you think about it, nowadays, you're not chatting anymore. You're essentially collaboratively editing a shared chat history file, where the most common action is to add a message; usually at the bottom.
This is what Matrix is at its core. It's a protocol to synchronise state, and that's part of why Matrix is so complex and hard to administrate. I personally think its the better base for the future of communication than XMPP, and I havent even mentioned encryption yet.
Moving on to the practical part: Running a Matrix Synapse server is quite a commitment, but if all you want is talk to friends and family, then there are simpler options. Conduit and Dendrite are a bit easier to set up, and of course there are plenty of public homeservers you could sign up with.
If you do commit to running Synapse however, you have the option to install bridges to almost any other messaging service. This way, your friends and family can keep using what they're used to (WhatsApp, Telegram, Discord, Facebook, ...), and you just use one single Matrix client to talk to all of them.
Wayland is perfectly ready to be used for normal desktop applications, but the devil is in the details.
Lately, I struggled with:
(1) a flickering bug in the NVIDIA driver only affecting Xwayland
(2) streaming to my TV via SteamLink
(3) reduced performance (compared to X11) on very old (2013) hardware
I fully support the idea of Wayland, but it needs to be adapted better for games.
When I was little (about 20 years ago) I found a website where you could download sheets to print out. They contained parts to cut out that would make an elaborate little glider airplane. You layered multiple layers of paper together and glued them. It included many different parts, but all of them were just paper in the end of the day.
I think the site is gone, I can't find it anymore. It had a blue background and about 10-20 designs available for download. It was either German, Swiss, Austrian, Italian or French, but I'm pretty sure it had multiple Languages.
> Our job is to write programs that run well on the hardware that we are given.
I actually believe "the hardware that we are given" is the entire root of the problem.
Most programmers work and test using whatever hardware is current at the time, but this is makes them blind to possible performance issues.
Take whatever you're working on, and run it on the hardware of 5-10 years ago. If you still have a good experience, you're doing it right. If not, you should probably stop upgrading developer machines for a while.
Whatever your minimum hardware requirements are should determine your development machines. This way, you will naturally ensure your low-end customers have a good experience while your high-end customers will have an even better experience.
My game studio has been doing this for years. It saves money for expensive hardware, it prevents performance issues before they arise and it saves developer time for not having to overthink optimization.
At runtime, booleans are 1 byte each. The additional work of shifting and masking to get to the bit you want simply isn't worth it. When reading from memory, the CPU will read a whole cache lines of 64 bytes anyways. So unless you want to process a lot of booleans (and only booleans) at once, it's simply not worth having them 1 bit each.
Because aligned data runs faster, a single boolean sandwiched inbetween integers or pointers can even take up 4 or 8 bytes of memory.
Note: Some languages have built-in optimisations where an array of booleans is actually 1 bit each. C++'s `std::vector<bool>` is such a case and I'm sure there are more.
I've seen people advise to never use booleans, simply because a number (or enum) can convey more meaning while taking up the same amount of space.