stuart@BMS-AT.UUCP (Stuart D. Gathman) (11/04/86)
We have been using Berkely curses and termcap on an otherwise SysV 6350
from Motorola. We now have to work with a SysV 8000 which has the
"new and improved" curses and terminfo from AT&T.
We have gotten used to having to "compile" the terminal types.
We realize why the capability names are fixed (standardization).
BUT,
A 30K curses program on the 6350 is 60K on the 8000.
A non-curses program on the 8000 is typically 25%
smaller than the identical C code on the 6350
because of optimization.
We cannot use MINI_CURSES because it doesn't support
getxy() and inch(). We don't need attributes, but
if I can't read the screen, I have to keep my own copy! :-(
I thought the new curses was supposed to "nifty", "small" and "fast"?
"nifty" is a matter of taste.
"small" is a lie.
"fast"? It might possibly use less CPU, but it takes twice as long
to load the programs!
BTW,
We also ran curses/terminfo on a Motorola 290 with the
same results.
Is this true for curses/terminfo everywhere else?
--
Stuart D. Gathman <..!seismo!{vrdxhq|dgis}!BMS-AT!stuart>ricker@bunker.UUCP (ricker) (11/06/86)
In article <257@BMS-AT.UUCP> stuart@BMS-AT.UUCP (Stuart D. Gathman) writes: > A 30K curses program on the 6350 is 60K on the 8000. > > A non-curses program on the 8000 is typically 25% > smaller than the identical C code on the 6350 > because of optimization. > 1) I don't know about the differences between a 6350 and an 8000 but, do you know if the compiler is the exact same on both systems? 2) Terminal-independent code is most likely going to be larger than terminal-specific code. Trade-offs ya know :) Running terminfo/curses on an altos is not terribly depressing although of course not perfect.
guy@sun.uucp (Guy Harris) (11/08/86)
> > A 30K curses program on the 6350 is 60K on the 8000. > > > > A non-curses program on the 8000 is typically 25% > > smaller than the identical C code on the 6350 > > because of optimization. > > > 1) I don't know about the differences between a 6350 and an 8000 > but, do you know if the compiler is the exact same on both systems? From his statements, it seems to me as if he knows that the compiler is, in fact, NOT the same on both systems - and that it produces BETTER code on the machine where the "curses" program is bigger! > 2) Terminal-independent code is most likely going to be larger than > terminal-specific code. Trade-offs ya know :) What does that have to do with the price of eggs? He isn't comparing the size of a piece of terminal-independent code with a piece of terminal-specific code here. He's saying that the "curses" code on the 6350 is smaller than the "curses" code on the 8000 - you can argue that both versions of "curses" are terminal-independent (because they're use the terminal databases "termcap" and "terminfo", respectively, to guide their actions). He mentioned the non-curses program just to show that the compiler is probably not at fault here - the program in question is bigger on the 8000 because "curses" is bigger on the 8000. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
guy@sun.uucp (Guy Harris) (11/08/86)
> I thought the new curses was supposed to "nifty", "small" and "fast"? > > "nifty" is a matter of taste. > > "small" is a lie. > > "fast"? It might possibly use less CPU, but it takes twice as long > to load the programs! > ... > Is this true for curses/terminfo everywhere else? I tried building the 4.3BSD "mille" game with both old and new "curses", and the new "curses" version was about 30K bigger. Comparing the "termcap"-based "ex" version 3.7 with the "terminfo"-based "ex" version 3.9, the "terminfo"-based version is about 9K bigger, so most of the 30KB increase is probably due to curses. CAVEAT: Under SunOS 3.x, program text and data sizes tend to get rounded up to 8KB boundaries, so there are rather large error bars around these numbers. Note, however, that the version of "curses" that was described as "fast and small" was the System V, Release 3.1 version. The version I used above was the System V, Release 2 version. The version that you have might possibly be the S5R3 version, almost certainly isn't the S5R3.1 version (somebody else may be able to change that "almost certainly" to "certainly" - I don't think S5R3.1 is released yet); the odds are that it is the S5R2 version. I infer from what Hansen said that the S5R3.1 version is much changed from the older S5R2 version (I know there are a number of changes between the S5R2 and S5R3 versions). As such, you should wait until you see the S5R3.1 version before you argue with Hansen's claim that it's "fast and small". -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)