More on compression

7 Comments to “More on compression”

1. Christopher Egner says:

   Tuesday, November 14th, 2006 at 7:56 am

   You know what would be interesting is to see is the processor time used by each. Most people will be doing other things at the same time, so why not see what it would take away from the user.

   Reply
2. Ben says:

   Tuesday, November 14th, 2006 at 11:03 am

   gzip and bzip2 aren’t as culpable, but archivers like 7Zip and WinRAR in “best” mode eat up as much CPU as you’ll allow them, which is why they come with options to run the compression in the background. I’m not sure WinACE has this option, and while the UHARC frontend I used was very nice, it doesn’t have such an option, either.

   UHARC is so interesting to me, because it was the archiver for a long time, especially in the warez scene. I still remember seeing Class rips that had to be unpacked and injected with sound files. Then, at some point, RAR became the de facto standard for compression in the “Scene,” even though its multimedia compression doesn’t particularly impress me. Blame the ready availability of the unrar DLL, and the limitations inherent to UHARC: once games got to be over 2GB in size, there were some problems, apparently.

   As I said before, some formats like PAQ or RK were so ridiculous in their requirements as to be untenable for realistic desktop use. UHARC pushes the limits (especially decompression time), but I included it as a foil for WinRAR (UHARC being the first widespread compressor with a multimedia filter, iirc) and also because there are some nice GUIs for it now.

   Reply
3. Kabari says:

   Wednesday, November 15th, 2006 at 4:22 am

   Hey Ben! I stumbled across this site and just wanted to leave a post saying what’s up. Good to see you’re doing well! Are you still studying English man? I just got my English degree and am going to be attending UofC for grad school.
   Take care,
   -Kabari

   Reply
4. Ben says:

   Wednesday, November 15th, 2006 at 8:28 am

   Well, color me surprised. It’s been a hell of a long time, Kabari. I’m actually not studying English as a major (I’m an Info Tech guy—can you tell by the content of the above post?), but I haven’t been taking a number of English classes for fun and presenting at conferences (look at the bottom of the Colophon)

   Reply
5. Ben says:

   Wednesday, November 15th, 2006 at 8:30 am

   By the way, I love your company. Standards-based, Web2.0-y design? Yum.

   Reply
6. Kabari says:

   Thursday, November 16th, 2006 at 2:56 am

   Thanks! Good read by the way. I was looking for compression info because I wanted to compress my javascript files but wasn’t sure how much of a difference gzipping would make.

   Reply
7. Ben says:

   Thursday, November 16th, 2006 at 9:45 am

   For javascript, a fair bit, but it has to do with how much bandwidth you expect the the first place. On my meager workstation here at work, gzip with default switches compresses the prototype.js library to <25% of its original size in about 47 milliseconds. Provided you’re caching efficiently on the server side, and you have visitors who are using browsers capable of unzipping on the client side, you could see a significant savings in bandwidth and load times.

   The real question, though, is whether you want to run compression with Apache (mod_deflate, for instance), which will compress everything compressible, or if you want to use the native compression capabilities of the language you’re working with. PHP has a rather effective gzip handler that you can use just by sticking the following code at the top of your javascript file and changing the extension to .php.

   
   <?php
   	ob_start ("ob_gzhandler");
   	header("Content-type: text/javascript; charset: UTF-8");
   	header("Cache-Control: must-revalidate");
   	$offset = 60 * 60 ;
   	$ExpStr = "Expires: " .
   	gmdate("D, d M Y H:i:s",
   	time()   $offset) . " GMT";
   	header($ExpStr);
   ?>
   

   Reply