Martin Writes:
On a SUN Ultra 2 running Solaris 2.6, your LZHU90 encoder in all of my
tests was slower than mmencode V2.7 (used for base-64 encoding). And
this with having complied using 'gcc -O3'. Without '-O3' it's even
slower ...
Martin, telling the compiler to optimize the code will not do what I call
optimizing code.
The code needs to be rewritten to work faster and compress more _BUT_ this
would be done by implementors...
Therefore, any comparision is not truely fair since I assume the Base64 code
I am using has be optimized to its fullest potential by Microsoft whereas
the LZJU90 code is not.
The rewriting of the code does not interfere with the LZJU90 algorythm, ie
no optimized encoders/decoders may handle optimized encoders/decoders just
fine.
So your statement isn't worth much, if you don't say which base64
encoder you used for comparison!
I have restated the mailer...
I thought I mentioned in a previous post that for all comparisions I would
use Microsoft Outlook Express version 4.72.3110.5.
I used the followin method to time----
In Outlook Express:
This may be timed by first attaching an object to a piece of email -begin-
the timing after you specifiy the filename in the "Save As" dialog box.
In the LZJU90 encoder:
Begin timing after you type the command line.
From current testing (so far, LZJU90 will _ALWAYS_ do better than
bas64 on raw data)
This will not always hold true depending on the type of internal
compression an object may have.
Did you read my former posting? There was one example, where the
LZJU90 encoding _was_ bigger that base64 _though_ it's been raw audio
data. So your statements above are wrong and misleading.
I read your post... My statements are NOT misleading, what type of audio
object did you compare?
I used LZJU90 on tease.wav. Wave files are raw audio....
The original wav file was 40.7kb
The Base64 file was 57.6 kb
The LZJU90 file is 52.6 kb
What is misleading about this? LZJU90 encoded the object faster... (sorry I
do not have a stop watch :-)
I'd put it this way:
LZJU90 applied to raw data most of the time yields smaller results
than base64 encoding, applied to data with internal compression
LZJU90 (nearly) always yields bigger results than base64 encoding.
This is an incorrect statement. It is now YOU who are misleading people.
LZJU90 will _ALWAYS_ (at least I have not come across a time when it has not
[yet]) produce objects that are smaller than base64 encoded objects [not as
you say most of the time] if that object is RAW. It will always be faster.
(At least it is with Outlook Express)
It will also compress text documents better.
I have not tested it on may items that have builtin compression, you second
statement may be correct.
Even so, it is my firm belief it would be a worthy endeavor to
include LZJU90 into the MIME spec.
Well, _if_ you can perform miracles and can convince many authors of
MIME aware MUA to support LZJU90 (though I and prOPABLY THEY can't see
any good advantages of it over "normal" compression plus base64), I'll
be happy to use it in the few situations where it's useful ... :)
I do not think it will take a miricle Martin, I think it takes work and
effort to produce documents that contain R&D. Alot of work went into LZJU90
and this work should not be slighted. It easy to rip something apart, very
hard to build.
Please believe me that if you take the time to read the draft, follow the
specification and re-write the c code optimized for your platform you MAY
see quite a difference. (but this would take work?)
Furthermore, this encoding is necessary to the internal structure of FS
(DATA portion of objects). The secod I-D I submitted.
I believe LZJU90 to be superiour to Base64 in many ways but a few.
Careful testing has shown that it does not work well with RealMedia video or
video/audio objects. Base64 does a somewhat better job.
When moving an entire file system, as the FS draft defines, a transfer
encoding is needed that is Fast and does a good job on many different types
of objects. LZJU90 achieves this goal.
LZJU90 was defined as a general files system object encoder/decoder, as
such, it may not work well with all objects -but- will work well with most
and I believe more than Base64.
I am building an example directory:
http://www.akc.com/fsa/examples
I am providing:
The orig. object, the base64 object and lzju90 object.
I believe in this way, the community will be able to inspect the work for
validity.
Regards to all,
-Al