TMEdit The Ultimate App-V Package Editor
To Documentation Index
Package Compression Options
When you save an App-V package in TMEdit, you will have an option to select how the compression is performed.
While the AppV file is based on the PKZip compression standard, it involves more than just zip compression, which is why you can't use standard zip utilities to create packages. But the PKZip standard includes the ability for the compression utility developer to use flexibility in his algorithms, trading of resource usage for compression effectiveness. The standard calls for 7 compression levels, but most implement either two or three options. These often have labels akin to:
- Fast - Use minimal Memory and CPU resources to compress but results in a less effective compression ratio.
- Medium - A balanced selection.
- Best - Use more resources to compress to get a highly compressed result.
It all basically comes down to how the searching is done to find strings to replace. This includes how small and how big of replacement things to look for. Look for smaller things and you find them more often but your dictionary is huge, look for bigger things and you chew up more CPU to find them. The specification allows for a lot of creativity on how to build the dictionary, but only one way to do the decompression from the resulting file.
We have determined that the App-V Sequencer uses a "fast" algorithm. But in testing at the Client we have learned that all compressions are supported and that compression ratio does not (significantly) impact decompression resources. I say significantly because of course there is a difference; but it need not be a negative one. It really depends on the latency to the source package and the speed of disk that you are decompressing into. It might be a little faster or a little slower, but in any case it is such a small difference that it is hard to measure the difference. So why not spend a little more time packaging, eat up less disk on the server storage, and transmit less over the network? That's what we thought. So we give you three options for compression when you save the package:
Fastest Compression
If you select the Fastest option, you will probably still get a smaller package than the original. This is in part because of how the Sequencer compression is tuned and in part because we tend to reduce the size of the registry.dat file (eliminating wasted space) when we repackage.
Balanced Compression
If you select the Balanced option, you will you will get something in-between the other two options.
Best Compression
If you keep the default option of Best, which we recommend, you'll get a smaller file. On a package with a large registry we have seen up to a 15% decrease in package size.