This is more of an idea I had yesterday but didn’t feel like typing it out, so ima type it out today what about build in Ram caching for apps like When you open an app, Haiku stores its code and resources in RAM, along with this it allows for smooth multitasking and does cause the OS to lag since it all being loaded from the Ram while also giving haiku the fast feeling that spread to it Apps, we could also make the assumption that when Haiku app/game are used via ram caching the executable code, assets, textures, and libraries are already in memory allow for the cpu to do barely any work which make for smoother animations, smoother scrolling in the OS, zero micro-freezes even during heavy tasks.
I you weren’t typing out all in one big sentence, I would be more sure that I understand you correctly.
As far as I understand you, you are talking about virtual memory. That’s pretty standard nowadays.
1 Like
Not necessarily. Haiku does use virtual memory, but that only comes into play when it runs out of real RAM. What @Philipingram25 describes sounds more like the MacOS and RiscOS system, where closing the last window doesn’t close the actual program, it is still there in memory waiting to get called on again.
So if I’m reading this on a MacOS browser. I can close all the tabs, but the browser remains in memory. Then when I need a browser again, all it needs to do is open a new tab, the engine was still loaded. You have to explicitly Quit the program to remove it from memory.
On MacOS, this is a necessity, because the Apple packaging system is inherently wasteful, with every app bundle coming with its own set of libraries. Don’t know why RiscOS does it, probably just to go along with its general weirdness.
Haiku native apps don’t need this. GTK/QT/Java ports OTOH …
1 Like
Well that’s not what I read, but Phil’s description is so vague that it can apply to a lot of things.
So, how does Haiku use RAM?
There are a lot of things that are done transparently.
When you run a program, it is loaded into RAM because that’s the only place where the CPU can execute it and access its data. Usually Haiku apps are small and will fit entirely into the RAM. They are removed when you exist them, and reloaded when you start them again, to make sure the newly started app runs with a fresh environment. But keeping an app “in standby”, running in the background with no windows open, is also an option as Michel mentions.
Typically, even with many apps running, you will still only use a small portion of the RAM. We don’t want the remaining space to sit unused. So, we use it as caches to speed up disk transfers. In Haiku, there are two types of caches, the file cache that stores file content directly (accessing that almost doesn’t hit any filesystem code at all), and the block cache that stores disk blocks, that the filesystem itself accesses frequently. We use this caching system to play a few other tricks. For example, Haiku application packages are compressed. Loading an application from a compressed package and unpacking it is somewhat slow. But, we use th cache to store the decompressed version of files in RAM. As a result, the decompression only happens once and then the data is stored in the cache.
You can additionally use the RAM as a RAM filesystem. If you want to save some files into RAM, which is very fast, you can do so in this way. There is one ramfs already available in /var/shared_memory (a bit of a weird path for this, but that’s where it’s set up by default at the moment). You can store files there if you want them to live in RAM, but they will be gone at the next reboot since they are not stored to disk. But usually you can trust the caches to do a good job of keeping your files in RAM already and you shouldn’t just copy files from disk to the ramfs.
Interesting things can happen when you use up all the memory (because you run several big applications). At first, Haiku will make space by reducing the size of the caches. That will slow down disk accesses, but applications will continue to run fine. If that isn’t enough, you will start to encounter swapping. That means Haiku is moving some applications out of the RAM and into disk storage temporarily, to free RAM for something else. This will usually slwo things down quite a bit, as things will be moved between RAM and disk a lot, and disks are slow. But you can get out of it by simply closing some apps to free up some RAM again.
1 Like
Uhm, all that and …
If one needed a UI-app to stay in memory, Haiku would need something similar to the Macintosh menu (or the GEM menu in Atari’s TOS), so that one could click the “New” or “Open” menu item to open a new window.
Haiku’s menu is inside a window, so that makes things a little different.
Of course, the Deskbar could be used for creating a new empty window, where the user can pick “New” or “Open” from.
… but speaking about RAM-cache; RAM-disks could be useful when building (especially ported software), so that the disk will not be needed to store object-files (temporary files). It’d help SSDs live longer and it’d make builds slightly quicker on harddisks / USB-sticks (that is, if you’re not running a “bare minimum RAM” system).