OptimizeFor=Disk

[ArdB]

I wanted to rebuild an old package. It was captured and build with 4.0.0. I needed to rebuild it because of windows 7 issues. After rebuilding with 4.6.1 the size grew from 47Mb to 315Mb. The compression type did not have much effect.

After some analyzing i noticed that one dll let the size grow by about 200 Mb although the dll itself was only 93KB. I tried also older versions, only 4.0.4 gave the same result as the original version.

The solution seemed to be the setting OptimizeFor=Disk , however I don't understand how this can happen. What does this setting really do that can create such a huge difference. The original size of the original files is only 47MB so how can this become so large ? Why does OptimizeFor also effect the package size when it CompressionType=None.

build results:

CompressionType=None

OptimizeFor=Memory

Filesize -> 316Mb

CompressionType=None

OptimizeFor=Disk

Filesize -> 47Mb

CompressionType=Fast

OptimizeFor=Disk

Filesize -> 25Mb

Discription of this parameter:

The OptimizeFor parameter controls whether to compress executable files or to reduce memory consumption and page file usage on the hard drive to improve startup performance. You can use this parameter with the CompressionType parameter to customize the package size, memory allocation, and application startup time.

[pbjork]

You can find some more information regarding the compression and OptimizedFor in this 4.5 release blog post.

[ArdB]

I understand the function of this. However this does not explain a size increase 250Mb. Looks like a bug to me.

[pbjork]

A developer should really answer this but as far as I got it explained to me are we storing dll:s and exe:s with surrounding zeros so they can be loaded into memory much quicker and memory pages can be shared (memory footprint being the same as the one on disk).. I wouldn’t expect one dll produce such big difference but having a package with many exe and dll files can very easily grow in size compared to pre 4.5 format using compression.

If you turn on compression but not change OptimizeFor will we only compress files other than exe and dlls.

[ArdB]

Thats good to know. I opened the thinapp exe in a hex editor and indeed it consists almost completely of 0 byte data. Compressing the large exe file into a zip file gets it back to 25 Mb again.

Somehow these dll's get analyzed by thinapp I assume and something goes wrong there. Renaming the dll did not fix the problem by the way so it inspects all files and somehow determines the memory order/location.

[shrivastavaa]

In case you are really interested in technical detais, the answer lies in the way a PE file exist in memory and at disk. If optimized for memory, thinApp can simply read the file from PDC and map it into memory. Where as in case of optimized for disk (which actually means JUST ""old functionality"); ThinApp need to do the conversion before mapping it to memory.

So optimize for memory is basically saving you time to load a binary file in thinApp applications.