[Toc][Index]

When Not to use ZipStream


We have tried to make ZipStream as general purpose and easy to use as 
possible, and we are continually providing improvements.  For the most 
part anything you can do now can be done safely with ZipStream providing a 
compression benefit.  There are however, some limitations to its 
operation. 

Device Drivers 
Do not compress or store OS/2 device drives on a ZipStream path.  The 
reason for this is that OS/2 loads device drivers prior to the loading of 
File System's during the OS/2 boot sequence.  This means, that when OS/2 
tries to load the device driver, the path and de-compression system will 
not yet be available to OS/2, and subsequently the load will fail. 
It is most important to realise that even if the file is not compressed, 
it still will not load, as the path provided by ZipStream will not be 
available when OS/2 loads device drivers. 

OLTP Systems 
Do not use ZipStream to compress large database files (i.e. over say 10MB) 
for Online Transaction Processing Systems (OLTP).  The reasons for this 
are as follows: 
 1. ZipStream utilises background compression and will get well behind the 
    OLTP system, making it rather ineffective. 
 2. ZipStream tries to keep whole files in its Virtual File Cache for 
    performance reasons, but if a file is being updated continually, the 
    cache will be continually flushed, which negates its performance 
    benefits. 
 3. Large database systems like these are always better off implementing 
    their own specific compression system, as a database, by its very 
    nature, understands the data content, and can apply a more effective 
    compression algorithm than a general purpose compression system. 



Created using Inf-PHP v.2 (c) 2003 Yuri Prokushev
Created using Inf-HTML v.0.9b (c) 1995 Peter Childs