sparks@corpane.UUCP (John Sparks) (08/04/89)
<20904@cup.portal.com> <26872@agate.BERKELEY.EDU> <1331@osupyr.mps.ohio-state.edu> <PORTUESI.89Aug2152814@tweezers.esd.sgi.com> Sender: Reply-To: sparks@corpane.UUCP (John Sparks) Followup-To: Distribution: na Organization: Corpane Industries, Inc. Keywords: In article <PORTUESI.89Aug2152814@tweezers.esd.sgi.com> >In Mike's earlier message, he said that the 12K savings from using ARP >commands over AmigaDOS commands was "insignificant." Well, I haven't >had my hard disk long enough to forget what using a floppy-based >system was like, and 12K is very significant when you only have an >880K disk to boot from and half of it is taken up by necessary things >like libraries and devices. I used the program CRUNCH to squeeze down the size of the programs on my workbench. I saved around 20% of space. which is much more than 12K. Crunch lets you squeeze an executable program down, like arc or zoo would, but unlike those archivers, you can still run the crunched program. It loads the program into memory, unsqueezes it and runs it. The program takes no longer to load and execute than before. The time use to unsqueeze it is made up by the time saved to load the smaller code off of the disk. I don't know if crunch has been posted to comp.binaries.amiga before or not. I have crunch v2.0, if it hasn't been sent in before, I will be happy to submit it. -- John Sparks | {rutgers|uunet}!ukma!corpane!sparks | D.I.S.K. 24hrs 1200bps ||||||||||||||| sparks@corpane.UUCP | 502/968-5401 thru -5406 Beware of quantum ducks: Quark, Quark.
jtreworgy@eagle.wesleyan.edu (08/07/89)
In article <934@corpane.UUCP>, sparks@corpane.UUCP (John Sparks) writes: > In article <PORTUESI.89Aug2152814@tweezers.esd.sgi.com> >>In Mike's earlier message, he said that the 12K savings from using ARP >>commands over AmigaDOS commands was "insignificant." Well, I haven't >>had my hard disk long enough to forget what using a floppy-based >>system was like, and 12K is very significant when you only have an >>880K disk to boot from and half of it is taken up by necessary things >>like libraries and devices. > > > I used the program CRUNCH to squeeze down the size of the programs on my > workbench. I saved around 20% of space. which is much more than 12K. > > Crunch lets you squeeze an executable program down, like arc or zoo would, but > unlike those archivers, you can still run the crunched program. It loads the > program into memory, unsqueezes it and runs it. The program takes no longer to > load and execute than before. The time use to unsqueeze it is made up by the > time saved to load the smaller code off of the disk. > > I don't know if crunch has been posted to comp.binaries.amiga before or not. > > I have crunch v2.0, if it hasn't been sent in before, I will be happy to submit > it. I have a similar program called PowerPacker (written by someone in Europe). This is a truly amazing program... on the average, of all the executables I crunched, I saved between 40 and 50% of the space. I don't have a hard disk, and after crunching them the total loading time (including loading & uncrunching) is actually less than with the uncrunched file. (This program probably wouldn't be nearly as useful to HD owners since you would lose a lot on loading time & presumeably space isn't as big a factor with a HD). It also has a built in hunk utility (allows you to force hunks into chip ram for those old programs that won't run in fast ram, among other things). It also has a script facility for crunching a lot of files overnight or something (it can take a LONG time to crunch, depending on the efficiency you use-- has five different levels). Uncrunching, however, is very fast. Fully intuition based, and the archive also includes two short stand-alone programs for crunching & decrunching data files. If anyone's interested, I'll UUencode it... James A. Treworgy "You should have seen me with the poker man, jtreworgy@eagle.wesleyan.edu I had a honey and I bet a grand, jtreworgy%eagle@WESLEYAN.BITNET Just in the nick of time I looked at his hand" Box 5033 Wesleyan Station -Paul McCartney Middletown, CT 06475
wendell@medsys.UUCP (bbs amiga user) (08/08/89)
Crunch 2.0 is a pretty efficient program cruncher, but also check out Power Packer. I have version 2.2A, and average over 40% crunching! It's written by some guy in Belgium, and can be had off of most BBS's, and online services. Beware though: unlike Crunch, Master Cruncher, and some other crunchers, Power Packer on some files doesn't work optimally. It crunched Jrcomm 0.94A down to about 95K, but after running JRcomm, it only gives back about 20K. The rest is lost, and neither Sweep, or Flush could get more than 5K of it back... Master Cruncher only crunched it to about 110K, but gives back almost ALL of the ram after quitting the program. Keep in mind, that only happened to JRcomm, Emacs, and one other program on my bootdisk. All other files crunched very well, and gave back their ram after exiting...
ranjit@grad2.cis.upenn.edu (Ranjit Bhatnagar) (08/08/89)
I'm curious about the interaction of these 'cruncher' programs with the Resident facility. It seems reasonable that a cruncher, in order to reduce the disk space taken up by a program, compresses that program and then prepends a loader-uncruncher. Thus when you invoke the crunched version of emacs, for instance, it actually loads the uncruncher, which then loads and uncrunches the rest of emacs. The overhead of the uncruncher is made up for by the space saved. If this is the case, then if you make emacs Resident, what will be made resident is not emacs itself, but the uncruncher and the crunched data file. When you subsequently run the resident emacs, rather than running emacs directly from the preloaded image, it will uncrunch the datafile again into newly allocated memory - thus losing the memory advantages of resident programs. On the other hand, the cruncher could patch the operating system so that the uncrunching process is transparent to the resident facility. -ranjit "Trespassers w" ranjit@eniac.seas.upenn.edu mailrus!eecae!netnews!eniac!... "Such a brute that even his shadow breaks things." (Lorca)
jtreworgy@eagle.wesleyan.edu (08/09/89)
In article <13549@netnews.upenn.edu>, ranjit@grad2.cis.upenn.edu (Ranjit Bhatnagar) writes: > I'm curious about the interaction of these 'cruncher' programs > with the Resident facility. It seems reasonable that a cruncher, > in order to reduce the disk space taken up by a program, compresses > that program and then prepends a loader-uncruncher. Thus when you > invoke the crunched version of emacs, for instance, it actually loads > the uncruncher, which then loads and uncrunches the rest of emacs. > The overhead of the uncruncher is made up for by the space saved. > In the case of PowerPacker, the decruncher is less than 200 bytes. This is entirely insignificant compared to the savings for all but the smallest programs (why would you bother crunching something small anyway?) > If this is the case, then if you make emacs Resident, what will be > made resident is not emacs itself, but the uncruncher and the crunched > data file. When you subsequently run the resident emacs, rather than > running emacs directly from the preloaded image, it will uncrunch > the datafile again into newly allocated memory - thus losing the memory > advantages of resident programs. > I suspect if you made a crunched program resident you would meet with a very large guru, rather than losing some memory. Solution: don't. Will emacs even work from a resident state? I can't imagine such a large program is coded well enough. > On the other hand, the cruncher could patch the operating system > so that the uncrunching process is transparent to the resident facility. > Maybe, but probably much more trouble than it's worth. Just don't crunch things you want to make resident. -- James A. Treworgy "You should have seen me with the poker man, jtreworgy@eagle.wesleyan.edu I had a honey and I bet a grand, jtreworgy%eagle@WESLEYAN.BITNET Just in the nick of time I looked at his hand" Box 5033 Wesleyan Station -Paul McCartney Middletown, CT 06475
ranjit@grad2.cis.upenn.edu (Ranjit Bhatnagar) (08/09/89)
In article <422@eagle.wesleyan.edu> jtreworgy@eagle.wesleyan.edu writes: >In article <13549@netnews.upenn.edu>, I wrote >> I'm curious about the interaction of these 'cruncher' programs >> with the Resident facility. > >I suspect if you made a crunched program resident you would meet with a very >large guru, rather than losing some memory. Solution: don't. Will emacs even >work from a resident state? I can't imagine such a large program is coded well >enough. In fact, that turns out to be the case. I got PowerPacker last night and tried it out with ARes and Rez (but not Commodore's Resident). Packed programs which are made resident tend to crash. No problem - I don't like to make big programs resident anyway; with only one floppy drive and no hard disk, the packer is definitely worth it. By the way, I used to run the 1.2 extras emacs under Rez with no problems. These days I use dme because it's smaller. (But now that I have the packer, I can go back to big disk-hungry editors.) - ranjit "Trespassers w" ranjit@eniac.seas.upenn.edu mailrus!eecae!netnews!eniac!... "Such a brute that even his shadow breaks things." (Lorca)
mnelson@vmsa.cf.uci.edu (08/09/89)
In article <13549@netnews.upenn.edu>, ranjit@grad2.cis.upenn.edu (Ranjit Bhatnagar) writes... >I'm curious about the interaction of these 'cruncher' programs >with the Resident facility. (speculation deleted) > -ranjit > > >"Trespassers w" ranjit@eniac.seas.upenn.edu mailrus!eecae!netnews!eniac!... > "Such a brute that even his shadow breaks things." (Lorca) I'm not sure about the workings of the interaction of crunched programs and the Resident facility, but I can tell you what happened to me. I just obtained PowerPacker, and merrily went thru my C: directory crunching everything that seemed worthwhile. I didn't think about which commands were made resident. Upon trying to use a crunched resident command, ARes told me that the checksum was bad, and then re-loaded the command. This happens every time I use the command (sort of defeats the purpose of ARes). Solution: don't crunch the commands you wish to make resident. Note for floppy users: even with leaving the offending programs un- crunched, I freed up about 17% of my boot disk; enough to add lots of goodies to the C: directory. matt