cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Poor Performance when installed via MSI

Dear all,

I'm currently having a strange problem in which the application I'm working on performs extremely slowly when deployed via the re-captured MSI. The manually installed application actually runs almost twice the speed. Whilst the app performs slowly, the doesn't appear to be anything broken as such - no errors are thrown and functionality seems comparable to the manually installed version.

The package itself contains approx 1100 files and nearly 55,000 registry entries.

On compiling the application Merge Modules were incorporated where applicable.

A comparable Regmon trace from both systems during login of the application results in a 172MB file for the MSI compared to a 15MB file for the manual install.

The trace of the MSI installed one seems to be referencing the following key (and sub-keys) constantly:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18

File comparisons between the two installs and re-registering the files manually does not help the situation. Recompiling the application to not use MSMs also does nothing.

By chance, I discovered that running the WI Cleanup util - MSIZAP allows the application to run with exactly the same performance as the manual install.

If anyone has come across a similar situation to this, or has any clues as to why it may be happening I would be very grateful.

Many thanks in advance.
Scott
(1) Reply
My educated guess on what is taking place is that the COM Tables are being used to register various COM Libraries in the package.

When your main application calls these, they are used as an entry point into the Windows Installer autorepair, but the application relies so heavily on them, the check that's performed each time the entry point is called causes a performance hit.

When you build your repackager project, there's an Advanced setting in the project that you can disable, "Map registry data tot he appropriate COM tables". If you disable this and rebuild, it will register the COM Servers through the registry table, which is then not used as an Advertised resource, so there's no check when the COM class, types, progid, etc. are called.