Re: [gtk-list] Re: Proposed widget

[Kevin Handy <kth srv net>]

At 12:12 PM 5/24/98 -0700, you wrote:
>   Date: Sun, 24 May 1998 08:41:33 -0700 (PDT)
>   From: KC5TJA <kc5tja@topaz.axisinternet.com>
>
>   > I have to pay 25 DM for 8 MB. I have absolutely no problem to spend 2
>   > pizzas for Gtk+.
>
>   Problem is: Linux won't load all 5MB into RAM.  It will dump some
>   of that out to swap file.
>
>If so, then your linux has a huge bug.  Shared libraries, like
>executables, should page in from their resident locations on disk,
>avoiding the swap area altogether.  Staging through swap in unix went
>out of fashion prior to the introduction of shared libraries.

You just beat me to this item. I thought for sure that Linux did this,
but was not sure after so many posted that this shared/nowrite code
would swap out. Many other OS's (Alpha OSF/1, VMS, etc) that I have
worked with use the original binary instead of swapping this out.
(There is no reason to write out code that (has not been)/(can not be)
changed in memory. The MMU will get upset if you try (segmentation
violation)

>With 5M shared libraries, though, I doubt we'd see much win from
>optimizing page locations.  When we get up to 80M, then we should
>think about it.

Also, it only pull into memory the pages out of the library that you
are actually referencing. If you don't use them, they don't use
any processor memory. The only memory limit you will have will be
how much disk space do you have available (and with $350 disks that
hold 6.2 gigs, this should'nt be a major problem).

If you hall a huge number of widgets in at the same time, in a limited
memory area, then you may see lot's of disk accesses, but not much of it
will be actual swapping to the swap file. It will be reading code
out of image files.

>It's also possible to split the library into pieces.  This might help
>somewhat, though with a piddly 10M library, I doubt it's worth the
>effort.

I doubt that splitting the library up will reduce actual memory used
in any significiant way. Virtual memory strikes again.

>   Furthermore, we're dealing with harddrive space here as well.  a
>   5MB binary is absolutely *******HUGE*******, especially for a
>   single component.
>
>Actually, no.  5M is not all that much these days.  When you work with
>500M binaries, you're getting up there.  (and yes, I'm serious).
>
>   If you want to have such huge binaries, please make the switch to
>   Windows.  They have that sort of thing all the time.  I don't want
>   it.
>
>Disk is cheap.  Linux pages well.  What's your concern?

If you have used windows with these large images, you become concerned
because of the poor paging that windows does. When windows really starts
to page, you are really in trouble. Linux pages much much better.
Try running X11 on a 4Mb 386 sometime. Then try Windows95 on 8Mb pentium.
You'll get about the same performance.

>   If GTK is going to get much larger than 2MB, I will switch to using
>   LibGGI and implementing my own user interface.
>
>   Now, I have absolutely NO objections to having a 1MB or so
>   libgtk.so file, and having *extensions* to it, a la GGI.  That I
>   can handle.  But having a single, monolithic library that is all
>   inclusive is decidedly a Microsoft-ian way of thinking about the
>   user interface.
>
>We'd need to bench to be sure, but for small apps, I'd bet that the
>overhead of loading numerous pieces of shared libraries combined with
>the page rounding overhead would likely overshadow any possible wins.

Virtual memory is very confusing, because there are so many different
memory sized you are talking about in the one phrase: Physical
memory = how much is currently residing in core, Virtual size =
how much memory does the program 'span', and Swap size = how much disk
is required to swap out the process. Your swap size is likely
to be much smaller than your virtual size.

However, since it only loads those portions of the libraries that
you are referencing, you shouldn't have too many problems. Where you
need to be concerned is if all of the widgets call each other
excessively, thus pulling all of them into memory at the same time.

I'd still vote on a larger library to reduce the quantity of
re-developed code as much as possible, but maybe place some of the
stanger (rarely used) widgets in an extension library.
-------------------------------------------------------------
Kevin Handy  kth@srv.net         Accounting Software for
Software Solutions. Inc.         VAX/VMS Computer Systems
Idaho Falls, Idaho