Path: utzoo!attcan!uunet!husc6!rutgers!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.unix.questions Subject: Re: Sizes of various editors Message-ID: <8215@brl-smoke.ARPA> Date: 5 Jul 88 14:30:42 GMT References: <399@cantuar.UUCP> <11418@steinmetz.ge.com> <6056@megaron.arizona.edu> <8196@brl-smoke.ARPA> <4736@vdsvax.steinmetz.ge.com> <2157@pt.cs.cmu.edu> <4750@vdsvax.steinmetz.ge.com> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 29 In article <4750@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes: >If you assume the Operating system and windowing software takes up 2 Megs, >an editor that takes up 35% of your available memory can cause problems. For comparison, on a Sun-3 running SunOS 3.5, the host part of "sam" is text data bss total 57344 + 8192 + 25504 = 91040 and the interactive front end using SunTools is 614400 + 16384 + 23828 = 654612 This must be mostly Sun graphics libraries, since the corresponding 5620 DMD interactive front end is 28832 + 1388 + 4692 = 34912 Presumably on SunOS 4.0 most of the front end would be shared libraries, so that somewhere around 128K bytes total would be used by "sam". (This excludes storage that is dynamically allocated during execution.) The native Sun version of "sam" runs like a bat out of heck, since the host/terminal process interface bottleneck is much faster than when running over a 9600bps link. By comparison, "vi" is 131072 + 8192 + 128360 = 267624 and is not nearly so spiffy. The 4.3BSD version of JOVE, an EMACS subset that BRL gurus much prefer to "vi", is 106496 + 24576 + 83848 = 214920 which as you will notice is smaller than "vi". So EMACS lovers need not suffer too much on Suns.