People get excited about this all the time, sadly! RAM usage is more a developer concern. Modern OS use virtual memory, so the RAM is redistributed based on usage. A page of RAM (usually 4,096 bytes) may be true virtual memory, where modified pages are backed up in a swap file, or it may have files memory mapped, usually for reading, not needing swap, just the original file. Many library files are actually shared between many programs, say all written in C/C++ using libc, so your number might be higher as being blamed for hosting a library file! A very few pages like OS kernel and IO buffers may be wired in place, either temporarily or with no backing store.
GNUCash using XML in gzipped form needs to read all the data file, and then presumably gunzip'ing it in a stream, it needs to write that data into equivalent memory structures, converting strings to numbers in many cases. Now, if the GnuCash VM pages are not in use, their RAM can be taken over by other processes when needed and, if modified, after being written to the supporting file. If no other process needs more RAM, the GnuCash RAM usage remains high, but that is nice as if you do venture into those pages, they are already mapped in RAM. I have a Linux PC, where I run 'top' and can see the RAM and VM use of every process: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND . . .1286531 dgp 20 0 910160 260804 76840 S 11.0 1.6 0:20.02 gnucash . . . . My GnuCash is using 910 MB total virtual and 261 MB resident in RAM, but I have 16,384 MB RAM, so who cares? You might find similar numbers in 'Windows Task Manager'. RAM was a big deal for most earlier systems, when there was no VM support, no swap file, and shortages of RAM kept programs from coming off the scheduler. Now it is just a sort of cache for disk, which itself is now often a SSD, solid state RAM chips that do not lose data when powered off. RAM as disk cache is not to be confused with the Level 1, 2, 3 caches between RAM and the CPU to speed things up and avoid contention between CPU cores and the IO RAM access. If you have a program with a growing memory footprint, it first runs at l1 cache speed, then l2, l3, RAM and finally at disk speed. The caches also protect you from DRAM being busy refreshing, opening every row, as DRAM must do frequently. Many systems have a l3 cache in front of the DRAM. DRAM is also faster if it does not have to change rows, working in one column, so the cache helps that! Most of us cannot afford SRAM, which has no rows, needs no refresh. If you have a performance problem, the current cures are more RAM to your system max of the right speed to not slow things, SSD replacing HD, faster CPUs with more cores. More cores means other programs are not taking them from GnuCash. Intel CPUs have hyperthreading, so their cores can run 2 threads of the same program, but I doubt GnuCash is multithreaded! Threading is multiple CPUs possibly running around in the same program at the same time. I survive with 2 AMD cores for now! _______________________________________________ gnucash-user mailing list [email protected] To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
