Speeding up msi -- how?
Christopher
Ours is a 50Mb compressed InstallShield Developer Basic MSI .exe installer with 1600 components, each with 1 file, in 15 features. We have 7 custom actions (InstallScript + Python). Installing on a single-CPU 2.8Ghz P4 takes 3 minutes, which is at least 2 minutes too long.
So far we have been able to speed things up the most as follows:
- don't always log verbosely (30% speed up)
- get rid of CA calls to logging MSI even when logging is not enabled
- in a web-install build, download CABs by feature instead of by component (16%)
- reduce *size* of installed files by 40% speeds up install by only 6%
- reducing *number* of files has better speed gains, though we're not sure if it the number of files or the number of components that is making this improvement (will test today)
- get rid of custom actions (5s+ per custom action)
Any more ideas? It seems that a great deal of overhead is in having a high number of components and/or files. File size doesn't appear to matter, though.
Much obliged for any ideas.
Rich [Microsoft Windows Installer MVP]
"=?Utf-8?B?Q2hyaXN0b3BoZXI=?=" <temp9.not...@real-d.com.invalid> spake the secret code
<18D579D4-16D2-4574...@microsoft.com> thusly:
> - get rid of custom actions (5s+ per custom action)
This sounds really odd. I have written gobs of custom actions, both
in VBScript and in C++ and I've never had one take 5 seconds.
--
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
<http://www.xmission.com/~legalize/book/>
Pilgrimage: Utah's annual demoparty
<http://pilgrimage.scene.org>
Rich [Microsoft Windows Installer MVP]
"=?Utf-8?B?Q2hyaXN0b3BoZXI=?=" <anon...@discussions.microsoft.com> spake the secret code
<45D6F158-E353-42EE...@microsoft.com> thusly:
>The 5 seconds is only the overhead, too -- not the time the ca itself
>takes to compute. However these are InstallScript custom actions which
>may be the cause for those 5 seconds.
InstallSUCKScript has gobs of bugs. It leaks MSI handles and causes lots
of other grief (like you CANNOT perform a major upgrade if you use
InstallSUCKScript). I would never recommend using InstallSUCKScript
for a new project and I would recommend migrating to native MSI custom
actions when legacy InstallSUCKScript projects are updated to Windows
Installer.
Dennis Bareis
<anon...@discussions.microsoft.com> wrote:
>However my main concern for this post is speeding up our msi.
My guess is the high number of features and components.
If used in for a company (in a hopefully well managed environment)
there may be scope for breaking a large MSI like that into a number of
related smaller ones (break up arbitary on on some contents category -
apart from anything else this will reduce the amount of testing
required on a change).
My 2 cents worth,
Dennis
----------------------------
Dennis Bareis (dba...@KillSpam.labyrinth.net.au)
http://www.labyrinth.net.au/~dbareis/index.htm
Free MSI automation/creation tool:
http://www.labyrinth.net.au/~dbareis/makemsi.htm
----------------------------
Douglas Hogan
components to install, what the directories are for these components, check
whether the key paths already exist set install state properties for each
components, and so on. This may be whats causing the slow up. It is
impossible to tell without seeing the source code for MSI. There could some
non - O(n) code in there somewhere.
Regarding Installscript, does it provide any functionality that cannot be
achieved by VBScript, or JScript, given that there is direct support for
these languages in custom actions in MSI? Why not list the types of things
you are trying to achieve with InstallScript and maybe we can see if these
can't be achieved by a custom action instead?
Just my 50 cent,
d.
Rich [Microsoft Windows Installer MVP]
"Douglas Hogan" <dougla...@hotmail.com> spake the secret code
<eBdFEpb8...@TK2MSFTNGP11.phx.gbl> thusly:
>Regarding Installscript, does it provide any functionality that cannot be
>achieved by VBScript, or JScript, given that there is direct support for
>these languages in custom actions in MSI?
InstallSUCKScript doesn't add anything over custom actions. You may
need to write the CA in C++, however, since VBScript and JScript do
have limitations (they can't use COM interfaces that aren't automation
interfaces, for example).
>Why not list the types of things
>you are trying to achieve with InstallScript and maybe we can see if these
>can't be achieved by a custom action instead?
I'm working on a large install right now that we are migrating away
from InstallSUCKScript exactly because InstallSUCKScript has bugs and
problems that prohibit us from doing Major Upgrades or installing
properly on Windows Server 2003 (leaked MSI handles in an infinite
loop). It took two months of nagging InstallSUCK Corporation on a
*PAID* support incident to even get them to admit that their code had
a bug. A whole bunch of screaming and yelling later they've finally
admitted that other customers are reporting the same problem and
they'll get around to fixing it "sometime".
They suck.
Phil Wilson
If you look at the MSI file with Orca for a custom action for a VBScript or a
call on a C++ DLL there's not much going on in comparison to all the stuff that
needs to happen to get IS script interpreted and run. I think you'll see a call
to an embedded IS DLL which extracts the script from the Binary table and calls
the out-of-process COM server to compile and interpret it. If speed is what you
want, I suspect a call to a C++ type1 custom action is the lowest overhead among
the cases where something needs extracting from the Binary table and calling.
--
Phil Wilson [MVP Windows Installer]
----
"Rich [Microsoft Windows Installer MVP]" <legaliz...@mail.xmission.com>
wrote in message news:%23a6KW5Y...@TK2MSFTNGP12.phx.gbl...
Zweitze de Vries
news:18D579D4-16D2-4574...@microsoft.com...
First of all, turn verbose logging on again. It tells you the time when each
action started, so you can pin down which action (custom action or standard
action) takes all the time. The SDK can tell you what every action does,
which tables it accesses etc.
Personally, I got rid of InstallScript, and InstallShield DLL CAs. If you
include them, you'll loose a lot of time at the initialization of your
setup. Instead, I created normal Windows Installer CAs (type 1). Keep them
as small as possible, and have them do as much as possible (the DLL is
unloaded after each action).
--
Zweitze de Vries
Cyco Software
Rijswijk, The Netherlands
Christopher
- reducing number of components: 7% speed increase
- reducing number (not size) of files: 40% speed increase
- not registering COM servers at all (instead of via InstallScript CA): 25% speed increase (needs alternate method)
Apparently MSI poses a hard limit of 64 empty files per second that InstallFiles action can transfer. 1/100th s overhead is simply unacceptable. We are investigating alternatives to InstallFiles.
Rich [Microsoft Windows Installer MVP]
"=?Utf-8?B?Q2hyaXN0b3BoZXI=?=" <anon...@discussions.microsoft.com> spake the secret code
<EF5BAE28-06F4-424B...@microsoft.com> thusly:
>Apparently MSI poses a hard limit of 64 empty files per second that
>InstallFiles action can transfer. 1/100th s overhead is simply
>unacceptable. We are investigating alternatives to InstallFiles.
Well I doubt MSI is imposing a limit here, just that your setup is
giving it a run for its money.
Some things you can consider -- if your files are just data files (for
instance a clip art library), you can write a custom action that
unzips the data files into the target area from a ZIP file in your source
media. You will lose the ability to track and patch those files
individually through Windows Installer, since WI will know nothing
about those files. You will also need to write a CA that removes the
files on uninstall.
Personally, 3 minutes to install an application doesn't sound
horrible.
There is also the possibility that the MSI 3.0 engine will speed
things up for you without you having to do anything. Its in beta
right now (you may still be able to join the beta), but IIRC, its due
out in Q1/Q2 of 2004.
"Martin v. Löwis"
> Any more ideas? It seems that a great deal of overhead is in having a
> high number of components and/or files. File size doesn't appear to
> matter, though.
I found that having a large number of RemoveFile entries slows it down
quite a lot. So I replaced the listing of individual files to be removed
with glob patterns.
Regards,
Martin
Zweitze de Vries
news:EF5BAE28-06F4-424B...@microsoft.com...
A small remark:
Performance tuning is all about the big picture. In your case, you are
looking for a reduction of two minutes. So this investigation would only
have merit if you try to install at least 12,000 files.
Do you have a progress dialog, with a label that shows the file name being
installed? Try getting rid of it - this kind of UI is slow in most
situations.
Also try running silent installs. At least you'll know whether it's dialog
handling or not.
Most of all suggest creating a log, it shows the start time of each action.
It should help you detect which actions are faster, and which are slower.
Phil Wilson
to the system can all be undone with a rollback. There's a cost to that
recoverability. Have you tried an install with DISABLEROLLBACK set to 1?
--
Phil Wilson [MVP Windows Installer]
----
news:EF5BAE28-06F4-424B...@microsoft.com...
Luke Surace
> In tiing analysis, the InstallScript custom actions aren't what's slowing
down the installer the most. As such would rewriting them in another
langauge not resolve the speed problem.
Maybe try joining some of your features together and see if that helps.
You could run the install in log mode, and see what areas of the install
take up the time (either watch the log, or check the times in the log file),
then look at what functionality these areas run and move on from there.
Just to point out - if you run in verbose log mode the install time will
increase dramitically. I would never have this running unless you are trying
to solve a specific problem.