252 lines
13 KiB
Plaintext
252 lines
13 KiB
Plaintext
|
|
Ok, ok, I yield -- much of what follows has been removed from the manual page
|
|
and packaged separately as this README. Which means, of course, that absolutely
|
|
nobody will ever read it.
|
|
|
|
If that proves to be wrong, I hope the individual will drop a line to:
|
|
procps-feedback@lists.sourceforge.net
|
|
|
|
Just say "Ha, I read it!" and the author will die happy (but not right away).
|
|
|
|
Thanks.
|
|
|
|
|
|
## Table of Contents ---------------------------------------------------##
|
|
NOTES and Rantings
|
|
CUSTOMIZING the Sources
|
|
|
|
|
|
## 7. NOTES and Rantings -----------------------------------------------##
|
|
7a. The top Binary
|
|
To whom it may (should) concern: this top, even with its vastly
|
|
expanded capabilities, is only slightly larger than the old top.
|
|
Were it not for extensive help text and additional sort callbacks,
|
|
it would be smaller.
|
|
Throw source carelessly at objectives, it will
|
|
produce equally careless machine instructions.
|
|
example: (num_pages - an_address)/1024 == duh?
|
|
kicker: document result as broken, due to elf!
|
|
----------------------------------------------
|
|
I know you're out there, are you getting this?
|
|
|
|
Now, as for all those new capabilities like colors and windows and
|
|
highlighting, you'd expect this top to be the "mother of all pigs"
|
|
compared to old top -- right?
|
|
|
|
Yea, with this top expect following piglets:
|
|
. A smaller virtual image and resident footprint
|
|
. Slightly fewer major page faults
|
|
. A large reduction in minor page faults for SMP
|
|
. The same or better response time
|
|
. The same or even less CPU costs
|
|
|
|
Ideally any comparison of the old and new top should be against
|
|
the same libproc format (32-bit or 64-bit tics) and run in a true
|
|
or simulated SMP environment (producing separate CPU stats). This
|
|
latter requirement will coax old top into handling his own
|
|
'/proc/stat' access -- something this top always does, but with
|
|
less cost.
|
|
|
|
7b. Comparing Performance
|
|
Even with equivalent libraries and '/proc/stat' access, it's dif-
|
|
ficult to accurately compare tops using their own displays.
|
|
Results for these cpu-intensive programs (who frequently exceed
|
|
their time-slice) generally show a wide disparity in %CPU. This
|
|
is due to differing call patterns, kernel preemptions and the tim-
|
|
ing of process snapshots. For slightly better results, start each
|
|
program with the following commands:
|
|
./old-top -d 0.5
|
|
nice -n-10 ./new-top -d 0.4
|
|
|
|
While actually putting this top at a performance disadvantage, the
|
|
higher scheduling priority and staggered timing will periodically
|
|
yield a somewhat truer picture. You could even reverse those
|
|
roles and get similar results.
|
|
|
|
The most consistent performance results will be obtained 'off-
|
|
line', using your shell's time pipe or the time program itself.
|
|
And even in a single processor environment or without equivalent
|
|
libraries, total cpu costs (user time + system time) are similar.
|
|
|
|
However, this top's cpu costs ARE influenced by the capabilities
|
|
you choose to exploit, even if they don't SEEM to be reflected in
|
|
such timings. So let's examine some...
|
|
|
|
7c. Cost of Stuff
|
|
Colors Cost -- Nada (almost).
|
|
Once the terminfo strings are built (at and during a user's
|
|
behest) they are SAVED with each window's stuff. And while
|
|
there will be extra tty escape sequences transmitted because of
|
|
colors, it makes no difference which 'char *' is actually used.
|
|
|
|
Highlighting Cost -- Nada (maybe), or blame it on Rio.
|
|
On second thought, let's blame it on the user.
|
|
|
|
For row highlighting, there is only the cost of those extra tty
|
|
escape sequences (same as for colors). For column highlight-
|
|
ing, there is a fairly significant cost associated with column
|
|
transition management combined with even more tty output.
|
|
These increased costs are incurred on every task display row.
|
|
|
|
Sooo... hey USER -- do NOT highlight COLUMNS. You shouldn't
|
|
need a constant visual reminder of your chosen sort field.
|
|
However, if you forget which field top is sorting it can serve
|
|
as a quick visual reminder.
|
|
|
|
Windows Cost -- Nada (if just 1 window).
|
|
If more than 1 window, almost certainly NOT Nada so blame it on
|
|
reality. Colors are not an issue, but those sort fields are.
|
|
|
|
If we could trust the user to always select the same 'c' state,
|
|
'S' state and sort field (hey, why ya got multiple windows then
|
|
user, huh?) AND if we can trust someone to recompile top with a
|
|
#define enabled, then we could achieve 'Nada'.
|
|
|
|
Ok, not likely, so we're gonna' be doing multiple sorts. BUT,
|
|
it may not be as bad as it sounds. Those sorts involve point-
|
|
ers only. And, that's as good as it gets ! (right Mr. N?)
|
|
|
|
7d. The top Sources
|
|
top.h
|
|
Unlike his predecessor, this top has a proper header file. It
|
|
contains ONLY declarations, NOT definitions. And there are
|
|
several conditionals present to help with further customiza-
|
|
tions and experimentation. All are Off by default.
|
|
|
|
top.c
|
|
Hopefully proves that source code needn't be a disorganized,
|
|
misaligned MESS. And, WHO says a source listing shouldn't
|
|
occasionally make you SMILE? Why, top.c even does a darn good
|
|
job of following the suggestions in a document hardly anybody
|
|
seems to observe.
|
|
|
|
the Linus Torvalds CodingStyle guidelines ...
|
|
-*- -*- -*- on indentation + etc. -*- -*- -*-
|
|
well almost all, except for those stinkin'...
|
|
|
|
I suppose even Linus Torvalds is entitled to err now and again.
|
|
How so you say? Tabs, me' bucko, stinkin' tabs! That, plus the
|
|
simplistic position regarding indentation espoused in that other-
|
|
wise excellent document.
|
|
|
|
-*- Rant On, and on -*-
|
|
Let's compare two approaches to the tab/indentation issue with a
|
|
small code sample using tabs then spaces. This snippet happens to
|
|
be the key to top's use of dynamic colors on many static screens,
|
|
while also ensuring screen width isn't exceeded so as to avoid
|
|
line wraps. We'll view just the first 40 columns, assuming one
|
|
wishes to occasionally provide comments to the right of actual
|
|
code (you do, don't you?).
|
|
|
|
Then YOU decide which approach makes the most SENSE!
|
|
|
|
Stinkin' Tabs versus Spaces: the Linus way
|
|
Hey, where'd my +----+----1----+----2----+----3----+----4+
|
|
many code lines | while (*sub_beg) { :
|
|
up-and-gone-to? | switch (*sub_end:
|
|
| case 0: :
|
|
Gosh, wonder if | \ Tabs Induced / :
|
|
Linus expects a | case 1: :
|
|
fellow to stick | + WASTE-Lands! + case 5: :
|
|
his comments on | :
|
|
the left side?! | + Not a Living + :
|
|
| :
|
|
Ever see source | + line-of-code + :
|
|
with not enough | :
|
|
whitespace; and | / To Be Found! \ :
|
|
this is better? | default::
|
|
| :
|
|
Oh lookie here, \ } :
|
|
there's just a hint of REAL code! ----> if (0 >= room) b:
|
|
/ } /* end: while 'subtrin:
|
|
+----------------------------------------+
|
|
|
|
Spaces versus Stinkin' Tabs: the other way
|
|
+----+----1----+----2----+----3----+----4+
|
|
Wow, now this is | while (*sub_beg) { :
|
|
Visible hackin'! | switch (*sub_end) { :
|
|
| case 0: :
|
|
Hmmm, wonder how | *(sub_end + 1) = '\0'; :
|
|
many programmers | case 1: case 2: case 3: case:
|
|
read those lines | case 5: case 6: case 7: case:
|
|
from the LEFT to | cap = Curwin->captab[(int:
|
|
the RIGHT? This | *sub_end = '\0'; :
|
|
"innovation" may | PUTP("%s%.*s%s", cap, roo:
|
|
possibly benefit | room -= (sub_end - sub_be:
|
|
those particular | sub_beg = ++sub_end; :
|
|
kinds of people, | break; :
|
|
you agree? Duh! | default: :
|
|
| ++sub_end; :
|
|
AND, there might | } :
|
|
even be room for | if (0 >= room) break; :
|
|
unseen comments! | } /* end: while 'subtrings' */ :
|
|
+----------------------------------------+
|
|
|
|
Gosh, I just don't KNOW -- it's such a TOUGH choice...
|
|
|
|
Oh you Stinkin' Tabs: correspondence, Who-Cares; documentation,
|
|
Oh-Alright; even scripts, Well-If-You-Must. But you have NO place
|
|
within the code-space of MY C-source listing! So be gone
|
|
already!!
|
|
|
|
In Summation...
|
|
- If you want to use tabs to the right of the code, go-for-it.
|
|
But PLEASE, not ever in the C-source code-space, thank-you-
|
|
kindly. Just use three little ol' spaces (exactly 3, no-more,
|
|
no-less) where you WOULD have stuck a stinkin' tab.
|
|
|
|
We'll get far more READABLE files, much less WAISTED precious
|
|
horizontal space, more consistent CURSORS and on, and ON, AND
|
|
ON! Plus, without those awful *the-devil's-own-handiwork*, the
|
|
aforementioned document need NEVER speak of their EVILS again.
|
|
|
|
- Lastly, since SPACES (not stinkin' tabs) are SO beneficial,
|
|
maybe we should use just a few more of 'em. Some of those C-
|
|
thingies are VERY sensitive -- they don't like being TOUCHED
|
|
by any other syntax element! Which ones? Why these guys:
|
|
|
|
braces, reserved words and binary operators
|
|
( it's the TRUTH, they told me themselves )
|
|
|
|
It's so EASY to keep 'em HAPPY! And lo-and-behold, the combi-
|
|
nation of <sp>thingy<sp> turns out to be a darn effective bug
|
|
repellent, too. So much so, one can actually code while
|
|
TOTALLY NUDE yet still avoid them ol' bug-bytes (sic-sic)!
|
|
step
|
|
down_from
|
|
me_punctilious
|
|
soap-box_once_again
|
|
[1 +5 +5 +5 = huh?]
|
|
|
|
|
|
## CUSTOMIZING the Sources ---------------------------------------------##
|
|
|
|
Listed below are the conditionals available should you wish to recompile
|
|
this top. The author's favorite is: PRETEND4CPUS.
|
|
|
|
That's the #define allowing you to simulate an SMP environment, and
|
|
(perhaps) impress your friends. It's currently set to display four
|
|
separate CPUs, but could easily be changed.
|
|
|
|
Caution: do NOT use this provision in an effort to impress someone
|
|
who truly possesses such a machine! The fact that all 4
|
|
CPUs show the same dynamic results will likely have the
|
|
opposite effect.
|
|
|
|
Enjoy...
|
|
|
|
|
|
//#define ATEOJ_REPORT /* report a bunch of stuff, at end-of-job */
|
|
//#define CASEUP_HEXES /* show any hex values in upper case */
|
|
//#define CASEUP_SCALE /* show scaled time/num suffix upper case */
|
|
//#define CASEUP_SUMMK /* show memory summary kilobytes with 'K' */
|
|
//#define POSIX_CMDLIN /* use '[ ]' for kernel threads, not '( )' */
|
|
//#define PRETEND2_5_X /* pretend we're linux 2.5.x (for IO-wait) */
|
|
//#define PRETEND4CPUS /* pretend we're smp with 4 ticsers (sic) */
|
|
//#define PRETENDNOCAP /* use a terminal without essential caps */
|
|
//#define SORT_SUPRESS /* *attempt* to reduce qsort overhead */
|
|
//#define USE_LIB_STA3 /* use lib status (3 ch) vs. proc_t (1 ch) */
|
|
//#define YIELDCPU_OFF /* hang on tight, DON'T issue sched_yield */
|
|
//#define WARN_NOT_SMP /* restrict '1' & 'I' commands to true smp */
|
|
|