https://yarchive.net/risks/sgi_irix.html

PERFORMANCE UPDATE

"Indy: an Indigo without the 'go'". -- Mark Hughes

"X and Motif are the reasons that UNIX deserves to die." -- Larry Kaplan

>The performance story is just as bad. I was tempted to write simply,
"Try to do some real work on a 16 megabyte Indy. Case closed.", but
I'll include some details.

>In May, I listed some unacceptable Motif performance measurements.
Just before 5.1 MR, someone reran my tests and discovered that the
performance had gotten even worse. Some effort was expended to tune
the software so that instead of being intolerable, it was back to
merely unacceptable performance.

>We no longer report benchmark results on our standard system. The
benchmarks are not done with the DSO libraries; they are all compiled
non-DSO so that the performance in 5.1 has not declined too much.

>Before I upgraded from 4.0.5 to the MR version of 5.1, I ran some
timings of some everyday activities to see what would happen. These
timings were all made with the wall clock, so they represent precisely
what our users will see. I run a 32 megabyte R4000 Elan.

Test 4.0.5 5.1 % change
---- ----- --- --------

C compile of a 25 sec 35 sec 40%
small application

C++ compile of a 68 sec 105 sec 54%
small application

Showcase startup, 13 sec 18 sec 38%
May report file

Start a shell <2 sec ~3 sec ~50%

Jot 2 MB file <2 sec ~3 sec ~50%

>What's most frightening about the 5.1 performance is that nobody knows
exactly where it went. If you start asking around, you get plenty of
finger-pointing and theories, but few facts. In the May report, I
proposed a "5% theory", which states that each little thing we add
(Motif, internationalization, drag-and-drop, DSOs, multiple fonts, and
so on) costs roughly 5% of the machine. After 15 or 20 of these,
most of the performance is gone.

>Bloating by itself causes problems. There's heavy paging, there's so
much code and it's so scattered that the cache may as well not be
there. The window manager and X and Toto are so tangled that many
minor operations like moving the mouse or deleting a file wake up all
the processes on the machine, causing additional paging, and perhaps
graphics context swaps.

>But bloat isn't the whole story. Rocky Rhodes recently ran a small
application on an Indy, and noticed that when he held the mouse button
down and slid it back and forth across the menu bar, the (small) pop-up
menus got as much as 25 seconds behind. He submitted a bug, which was
dismissed as paging due to lack of memory. But Rocky was running with
160 megabytes of memory, so there was no paging. The problem turned
out to be Motif code modified for the SGI look that is even more
sluggish than regular Motif. Perhaps the problem is simply due to the
huge number of context swaps necessary for all the daemons we're
shipping.

>The complexity of our system software has surpassed the ability of
average SGI programmers to understand it. And perhaps not just average
programmers. Get a room full of 10 of our best software people, and
you'll get 10 different opinions of what's causing the lousy
performance and bloat. What's wrong is that the software has simply
become too complicated for anyone to understand.