From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Poll for the users of ZLib-Ada Date: Wed, 16 Mar 2016 19:15:42 -0500 Organization: JSA Research & Innovation Message-ID: References: <5c099b3d-2605-491e-921b-66a7a8eca885@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1458173742 12757 24.196.82.226 (17 Mar 2016 00:15:42 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 17 Mar 2016 00:15:42 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:29814 Date: 2016-03-16T19:15:42-05:00 List-Id: wrote in message news:ac986ae0-3c3b-40be-9858-56a121b2ecba@googlegroups.com... > On Tuesday, March 15, 2016 at 10:55:30 PM UTC+1, Randy Brukardt wrote: > >> Wasn't the purposes of those lower levels to use less CPU time and space? >> But that hardly matters anymore, because the difference between 0.010 sec >> and 0.022 sec isn't noticable (CPUs are 1000x), and we have oceans of >> memory >> compared to the 1980s when ZIP was invented. > > Well, 0.022 sec is more than the double than 0.010 sec! You'll notice a > kind of difference when you process large data... True, although I was thinking about for the human using a ZIP program and those being the total times. If, for compressing the your files, the total time is 0.022 sec vs. 0.010 sec, the human is not going to be able to notice the difference. After all, our first PC compiler took 7 days to process the ACVC. Today, the ACATS is much larger than those ACVCs, and the total processing time is about 90 minutes (and more than an hour of that is from real-time tests with lengthy delay statements). ... >> They probably need to exist because of compatibility with old ZIP files >> but >> even in the 1980s I don't think they were used much (I don't recall ever >> using them on purpose, although I think PKZip would sometimes decide to >> use >> them itself for whatever reason). > > Old (or new) Zip files need to be *decompressed*. > You don't need a compression software to read them, and even less to > choose a compression level, in the zlib sense. I was thinking that the library did both, as it seems weird to have a library that only works in one direction. (But I haven't looked at your Zip stuff in a long time, so I forgotten which part does what.) My somewhat uninformed take: (1) For compression, don't stress. It's unlikely to make enough difference. And if you *really* care about the best possible compression, you'll have to run trials. (2) For uncompression, one wants to support everything that you might encounter. Which would naturally tend to mean that you'd support it for compression as well (at least so one can test that it works). But probably not be default or even by trial, only if forced somehow. > What some versions of PKZip did was ... That's probably what I remembered. It's been a long time since I really cared (the packing of a bunch of files in one, not the compression, is what I tend to use ZIP for these days). Randy.