Re: [gtk-list] Re: Proposed widget
- From: "K. Richard Pixley" <rich kyoto noir com>
- To: gtk-list redhat com
- CC: gtk-list redhat com
- Subject: Re: [gtk-list] Re: Proposed widget
- Date: Sun, 24 May 1998 12:12:25 -0700
Date: Sun, 24 May 1998 08:41:33 -0700 (PDT)
From: KC5TJA <email@example.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.
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.
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
Furthermore, we're dealing with harddrive space here as well. a
5MB binary is absolutely *******HUGE*******, especially for a
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
Disk is cheap. Linux pages well. What's your concern?
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
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.
] [Thread Prev