Return to BSD News archive
Newsgroups: comp.os.386bsd.apps Path: sserve!newshost.anu.edu.au!munnari.oz.au!cs.mu.OZ.AU!slf From: slf@cs.mu.OZ.AU (Stewart Forster) Subject: Re: TCX -- transparent [un]compression of executables Message-ID: <9308914.14240@mulga.cs.mu.OZ.AU> Originator: slf@turiel.cs.mu.OZ.AU Sender: news@cs.mu.OZ.AU Reply-To: slf@cs.mu.OZ.AU (Stewart Forster) Organization: Computer Science, University Of Melbourne, Australia References: <9308509.26865@mulga.cs.mu.OZ.AU> <haley.733188816@husc.harvard.edu> <9308914.12697@mulga.cs.mu.OZ.AU> Date: Tue, 30 Mar 1993 04:44:23 GMT Lines: 74 Hi, In article <haley.733188816@husc.harvard.edu>, haley@scws3.harvard.edu (Elizabeth Haley) writes: > Ummm, are you aware that the current release of gzip comes with gzexe, > which does exactly what you say tcx does? I wrote TCX and was aware of gzexe about half-way through developing it, and thought to myself "Oh no. Someone's already done it!". Then I looked and thought, "Phew. Absolutely NOTHING like what I had done". > I would be interested in a comparison... OK! Here goes. The only thing in common between gzexe and TCX is that they allow for transparent uncompression of executables. That's it. Gzexe works by placing a short shell script on the head of each executable, after which it places the compressed form. This shell script invokes gunzip to unpack the executable to a /tmp file which may have a random name. It then invokes the executable in /tmp, waits for it to die, deletes the temporary executable and exits. PROBLEMS with gzexe * It uses /bin/sh which is an interpreter, and hence slowish. * If /tmp runs out of space it fails. * If the program relies on being called something (which some do) it will fail if there is already a file in /tmp by the same name. * When the program stops running, the /tmp file is deleted, which means it has to uncompressed again the next time it is run. * When there is more than 1 invocation of the executable running on the system, the system cannot benefit from shared text space, since gzexe will make two copies of the executable text, not one. * Gzexe remains running while the process it invoked is running, which means you needs to have 2 processes running for each executable you invoke. * It has an overhead of 326 bytes on the gzipped size (it adds up!) SOLUTIONS provided in TCX * TCX is a C program, not an interpreter (although it is invoked like it was one), hence it works faster. * Tries to unpack local executables in place to prevent overworking /tmp or filling it up. If the local filesystem runs out of space, it then tries to unpack to /tmp. Only if /tmp fills up then does it fail. * TCX will always ensure that a program is called what it should be, not some temporary name. * When the execution is done, TCX has timeouts to wait for reuse of the executable, so the system is not overworked by uncompressing all the time. * TCX ensures that multiple ivocations of an executable will share the same text space, hence NOT undermining the Virtual Memory performane improvements built into 4.2 BSD (and higher) * TCX does not hang around while the executable is running, so you only need one process, being that running the executable. There is a daemon running (invoked implicitly by the first person to run a TCX program when a machine comes up) which handles termination of processes. So there is n+1 processes, NOT 2*n processes, where n is the number of compressed executables being run. * TCX has an overhead of 28 bytes on the gzipped size (much better) That's about all I can quickly think of, but I'm sure there's still more differences. I started devloping TCX without the knowledge of gzexe, and consequently, a lot of effort has gone into a complete solution derived from an original plan, rather than just taking something and trying to make it better. Stewart. -- +-----------------------------------------------------------------------------+ | Stewart Forster Snr Systems Programmer - Dept of Computer Science | | Phone : +61 3 3444046 Richard Berry Bldng, The University Of Melbourne | | Email : slf@cs.mu.OZ.AU Parkville, 3052, Victoria, Australia. |