Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!sun.soe.clarkson.edu!nelson From: nelson@sun.soe.clarkson.edu (Russ Nelson) Newsgroups: comp.binaries.ibm.pc.d Subject: Re: lharc algorithm Message-ID: Date: 12 Apr 89 04:46:54 GMT References: <617@eecea.eece.ksu.edu> <10184@megaron.arizona.edu> Sender: news@sun.soe.clarkson.edu Reply-To: nelson@clutx.clarkson.edu Organization: Clarkson University, Postdam NY Lines: 29 In-reply-to: cjeffery@arizona.edu's message of 11 Apr 89 20:51:37 GMT In article <10184@megaron.arizona.edu> cjeffery@arizona.edu (Clinton Jeffery) writes: Lzhuf.c spends more than half its encoding time within a single routine, which suggests someone more clever than I could speed it up without sacrificing portability... I suppose I'm going to get flamed for this, but I added in-line assembly language lines to lzhuf.c and managed to improve both compression and extraction by half. That is, they both run about 1.5 times faster. Part of this gain is due to assembly language, and another part is due to really obvious things like using a 4K setvbuf on input and output, using fwrite in preference to fputc, unrolling loops, and keeping inner loops tight so as to give the compiler's optimizer a chance. So my code will be useful to everyone, not just those of us doomed to program under MS-LOSS. In general, if you want to speed up compression, optimize the inner loop comparing characters in InsertNode. This routine is very similar to memcmp except that it also tells you where the mismatch was. If you want to speed up decompression, speed up the hidden inner loop in update(). Look for that little while statement comparing k against freq. -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) America -- Socialism for the rich people, Capitalism for the rest of us. - Michael Harrington, Co-Chair, Democratic Socialists of America