BLOAT UPDATE

"Do you want to be a bloat detective? It's easy; just pick any executable. There! You found some!"
-- Rolf van Widenfelt

In the May report, I listed a bunch of executable sizes, and pointed out that they were unacceptable if we intended to run without serious paging problems on a 16 megabyte system. Between May and the 5.1 release, many have grown even larger. IRIX went up from 4.8 megabytes to 8.1 megabytes, and has a memory leak that causes it to grow. Within a week, my newly-booted 5.1 IRIX was larger than 13.8 megabytes -- a big chunk of a 16 megabyte system. It's wrong to require our users to reboot every week.

There are too many daemons. In a vanilla 5.1 installation with Toto, there are 37 background processes.

DSOs were supposed to reduce physical memory usage, but have had just the opposite effect, and their indirection has reduced performance.

Programs like Roger Chickering's "Bloatview" based on Wiltse Carpenter's work make some problems obvious. The news reader "xrn", starts out small, but leaks memory so badly that within a week or so it grows to 9 or 10 megabytes, along with plenty of other large programs. But what's really embarrassing is that even the kernel leaks memory that can't be recovered except by rebooting!

Showcase grew from 3.2 megabytes to 4.0 megabytes, and the master and status gizmos which are run by default occupy another 1.7 megabytes. Much of this happened simply by recompiling under 5.1 -- not because of additional code.

The window system (Xsgi + 4Dwm) is up from 3.2 MB to 3.6 MB, and the miscellaneous stuff has grown as well. As I type now, I have the default non-toto environment plus a single shell and a single text editor, jot. The total physical memory usage is 21.9 megabytes, and only because I rebooted IRIX yesterday evening to reduce the kernel size. Luckily, I'm on a 32 megabyte system without Toto, or I'd be swamped by paging.

Much of the problem seems to be due to DSOs that load whole libraries instead of individual routines. Many SGI applications link with 20 or so large DSOs, virtually guaranteeing enormous executables.

In spite of the DSOs, large chunks of Motif programs remain unshared, and duplicated in all Motif applications.

Let's try to concentrate on performance and quality, not on new features, especially for the 5.1.2 release. I know from my own experience that when I write good code, I spend 10% of the time adding features, and 90% debugging and tuning them. It's the only way to make quality software. In SGI's recent releases, the opposite proportions are often the rule. It's much easier to add 100 really neat features that don't work than to speed up performance by 1%.
Aim for simplicity in design, not complexity. Make a few things work really well; don't have 1000 flaky programs.
Be willing to cut features; who's going to be more pissed off: a customer who was promised a feature that doesn't appear, or the same customer who gets the promised feature, and after months of struggling with it, discovers he can't make it work?

16 megabyte system

WHAT YEAR IS IT?

>>3
we have more ram but does that make it ok for programs to use it all up?

>>4
unused ram is wasted ram

>>3
s/megabyte/gigabyte/g

>>3
Probably 1983

IRIX went up from 4.8 megabytes to 8.1 megabytes, and has a memory leak that causes it to grow.

That's what happens when you use software written in C.

Windows NT addresses 2 Gigabytes of RAM which is more than any application will ever need
— Microsoft on the development of Windows NT. ~ 1992

tfw 8 apps of ram

🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳
DUBS FOR DA PEOPLE
🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳

>>9
lets see these guys implement diff