How to calculate time required for compressing using zip?
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
bigrigdriver, I think the question is about estimating the time needed by the zip command, before actually execute it. My answer is no. The time required by the compression algorithm depends on:
1. the size of the original file
2. the kind of data inside the file
3. the load of the machine
4. the performance of the filesystem I/O
you can only do a rough estimate based on the file size, which is the only information you can get in advance. Just my opinion.
I would agree that you can't really calculate the time to compress a general file. You might, however, be able to measure the time to compress a similar file, depending on what you know about the files that you are going to want to compress. In many cases, getting an estimate of the worst-case time (greatest time that it could take) is enough. In which cases the 'how do you time...' come into their own.
I'm not sure that OP will get more useful information unless more can be disclosed about the application.
It is much more usual to use gzip to compress a .tar file, and there is no need to do it as a separate phase - just add the z option when making the tar file in the first place, and it will be created compressed.
A zipped tarball is unusual. Like tar files, zip files are a "filesystem in a file" - you can store multiple files and so on. They're not as suitable for accessing from a tape drive (which tar files were originally designed to do, but they include compression, which a tar file does not do on it's own.
So I would expect either .zip or .tar.gz (a gzipped tar file), or .tar.bz2 (a tar file compressed with the bzip2 program, which takes longer than gzip, but often results in a smaller size). You might also see .tar.Z, which is a tar file which has been compressed using the unix "compress" program.
Unlike zip, gzip, bzip2 and compress do not contain multiple files - they just contain a compressed version of one file.
I agree with the replies which say it is not really feasible to pre-calculate the time it will take to compress a file. There are too many variables. Your best bet is to do some tests with a system under common working loads, and get a feel for roughly how long it will take. Note that the runtime will rise sharply as the machine becomes heavily loaded.
Last edited by matthewg42; 08-01-2008 at 12:52 PM.