Runtime Resource Usage

Previous Top Next

Performance effects of running inside the Thinstall VM

General code execution

Traditional Virtual Machine technologies such as VMWare and Virtual PC slow down execution of programs by 25-50%.

Programs running inside the Thinstall VM execute exactly the same set of Intel instructions as they normally would, so there is no effect on CPU-only related activities.

Memory allocation and management

Programs running inside the Thinstall VM continue to use their native memory allocation and management system so there is no effect on allocation performance.

Thinstall allocates some memory using it is own private heap. The amount of memory required depends on many factors, including:

· Number of open virtual files: Each open virtual files requires 64k of memory

· The type of compression used: Use of Thinstall's "maximum compression" option requires 400k of additional memory per EXE.

· Number of objects tracked by Thinstall: Thinstall allocates a small amount of memory to keep track of each object created by your application.

· Threads running

· DLLs loaded

· Memory mapped files (see below)

· FindFirstFile pending operations

· Open File Handles

· Virtual Registry Key handles

Additional Memory required due to non-sharing of EXE and private DLL memory pages

When running a program under Windows, multiple running copies of the same EXE / DLL can share unmodified code pages across processes. When running in Thinstall multiple running copies of the same EXE / DLL do not share unmodified pages. This can result in higher memory usage in such circumstances.

Memory effect on Virtual Memory

When running a program under Windows, unmodified EXE & DLL memory pages are backed by the file memory map mechanism. When memory conditions are low, Windows can throw these unmodified pages away without writing to disk. When running a program under Thinstall, the pages must be written to disk before they can be swapped out. This can result in slower performance of virtual memory when the system is low on memory and your program is large but inactive. Because DLLs contain read-write data, Import Sections, and Code-relocation sections it is not uncommon for 90% of the DLL's pages to be modified. This means the resulting memory requirements differences between Thinstall'ed and non-THinstall'ed versions may be negligible.

Calls into external DLLs

Programs running inside the Thinstall VM may call internal and external DLLs with no effect on performance. When Thinstall's "Log API calls" or "Log Everything" options are enabled, then calls to DLL functions will be logged to disk and run significantly slower.

File system operations

File Open - File open performance is effected by Read Order and Caching options. By setting the Read Order to "Internal Only", you eliminate Thinstall's need to check for an external file located at the same location. Also setting the caching option to "Never cache or Extract" removes Thinstall's need to check for an external cache file. Cache files are only queried once per execution to determine their file time stamps and sizes.

File Read

Virtual Files: File reading performance of virtual files will vary depending on the compression option used, the speed of your CPU, and the speed of your hard drive or network drive. For fast decompression, the decompression speed often exceeds the hard drive read speed. When a virtual file has been written to disk due to write-caching, the read performance will be the same as normal system file reads unless cache-encryption has been enabled. Cache-encryption causes a decryption operation to be applied to all data read from disk.

System Files: File reading performance is unaffected.

Overlapped Reads

Virtual Files: Thinstall does not support overlapped reading from virtual files. Attempts to used overlapped I/O on a virtual file is simulated using synchronous reads. Applications expecting large overlapped I/O operations to complete in the background may experience poor performance. Very few Windows applications use Overlapped reading, so this is unlikely to affect anyone.

System Files: Overlapped file reading performance is unaffected.

File Seeking

Virtual Files: Thinstall decompresses blocks of 64k at a time. If an application performs a number of file seeks with small reads that trigger new block decompression, there may be a degradation of performance.

System Files: File seeking performance is unaffected.

File Write

Virtual Files: Writes to cache files do not have any additional performance overhead unless cache encryption is enabled.

System Files: File write performance is unaffected.

File Close

Virtual Files: Closing a virtual file has no additional performance overhead.

System Files: File close performance is unaffected.

FindFirstFile - Enumerating directories or files, virtual or real, has a higher overhead because both file systems are consulted to match wildcards. Depending on the file's read order and caching options, further filesystem activity may occur when a file is located to determine which file timestamps to use.

Memory-mapped file creation

Virtual Files: Performance will depend on caching options. If "Never cache or Extract" is selected, the file's entire data will be decompressed into a memory buffer. The application then thinks it is working with a memory mapped file, but really it is accessing a normal memory buffer. Closing the memory mapped file automatically destroys this memory buffer. The initial creation of this memory buffer can be very slow (and require a large amount of memory) depending on the size of the file. After the buffer has been setup, memory accesses occur much faster because application page-faults no longer occur, as would be the case for normal memory mapped files.

If caching is set to "Cache on Write/memmap", then the file's data will be decompressed to a separate cache file the first time a memory map is requested by the application. After this, there is not much difference from normal system files.

.NET uses memory mapped files to load .NET byte code for EXEs and DLLs, so loading performance of new code can be effected by this issue.

System Files: Memory-mapped file creation performance is unaffected.

SearchPath: Using SearchPath to locate files will have a slower performance because the internal archive is consulted along with the real filesystem.

DLL Loading (LoadLibrary) - Thinstall performs several operations for each system DLL used by your program, and will have a small overhead for each DLL loaded. Dlls loaded from the internal archive should generally be faster. For DLLs loaded under Windows 9X, a small temporary file is constructed in the user's TEMP directory which contains the DLL's resources. For WinNT/2k/XP this stub is not constructed. The stub is only constructed once per execution and deleted when the program quits.

Using the Module Search Order option "Always Load this DLL" prevents Thinstall from having to traverse the system search path to determine which DLL to load.

Network Performance
Thinstall does not have any effect on a program's network performance

Registry Performance

Thinstall does not significantly affect the performance of registry operations.

Threads

Thinstall does not significantly effect the performance of Thread Creation/Destruction. Because Thinstall may lock threads accessing shared objects at the same time, in some cases threads may be locked more than normal. For example Thinstall uses a single decompression buffer, so if 2 threads are trying to read compressed virtual files at the same time, one thread will block until the other has completed it is decompression operation.

Process Creation

Execution of external or internal EXEs using Thinstall can have various performance effects. Execution occurs through use of ShellExecute, CreateProcess, and OpenProcess. For EXEs executed from the internal archive, a small 4k stub is constructed in the user's TEMP directory; this stub file is constructed only once and left behind after the program quits (since the second process may still be running).

Executing a program without specifying a full path will be slower because the internal archive and system search path are queried at the same time to determine which EXE to execute.