Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!njin!idunno!cs!cs.Princeton.EDU!nfs
From: nfs@cs.Princeton.EDU (Norbert Schlenker)
Newsgroups: comp.os.minix
Subject: Re: Comic
Message-ID: <946@rossignol.Princeton.EDU>
Date: 11 Jul 90 03:57:26 GMT
References: <228@sun13.scri.fsu.edu>
Sender: news@cs.Princeton.EDU
Organization: Dept. of Computer Science, Princeton University
Lines: 30

In article <228@sun13.scri.fsu.edu> nall@sun8.scri.fsu.edu (John Nall) writes:
>The compression is good enough, however, so that it would bear
>some further investigation.  Two possibilities arise (which are
>not necessarily non-exclusive):  (a) vectorizing the code, and
>(b) profiling it and then going to assembly language for those
>parts which show up as chewing up all the execution time.

Bruce Evans has posted profiling data for 16 bit PC Minix.  I have
similar (but more outrageous) results from some Unix machines here.
The bottleneck is in memrchr(), which takes ~70% of the time used
by comic (this is the C version now, cmemrchr.c).  Since the PC
Minix code already has memrchr() in assembly, it's clear that
another approach is required entirely.

Kent Williams (I think, but I can't find the note now) has suggested
hashing to find strings, a la compress.  I suspect it is the only
chance that comic has.

On a related note, has anyone gotten lharc to compile on a Unix box?
Every one I've tried here fails to compile lhio.c without error, 
apparently because of an incompatibility with <dirent.h>.  Is there
an easy fix?

On a further related note, one can compile lzhuf.c with -DSELFMAIN
to get a (simpleminded) version which does essentially what compress
does, with much better compression.  The C version is about 1/3 as
fast as compress (using PC ACK); a few tweaks to the assembly code
allow it to run only about 50% slower.

Norbert