[GNC] GNUcash is using 538MB

[R Losey]

Just out of curiosity, I started GnuCash on my iMac, and then looked at the
Activity Monitor; it says it is using 168M.  I may try this on Ubuntu and
Windows later, just to see how it compares.


On Sat, Dec 17, 2022 at 2:53 PM David G. Pickett via gnucash-user <
gnucash-user at gnucash.org> wrote:

> 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
> gnucash-user at gnucash.org
> 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.
>


-- 
_________________________________
Richard Losey
rlosey at gmail.com
Micah 6:8