installer taking 100% CPU

[adrien]

we recently changed our installer to do all the "work" of installation in the On Progress event handler for the "while installing" screen.

This was done so we could show progress of our tasks, some of which can take a long time.

Prior to this, we did our actions in On Pre Install and On Post Install. This would cause nothing to be displayed by the installer (no screen at all - nada) for too long (over 10s) while we say stop a service etc. This could lead users to think the installer had crashed, and terminate it with task manager.

Ok, so we put absolutely EVERYTHING into the while installing On Progress event.

This included writing a LOT of registry strings. We only did this work if e_Stage == INSTALL_STAGE_PREPARING (for stopping services and apps), and if e_Stage == INSTALL_STAGE_CREATING_SHORTCUTS (to install service, install driver, set registry).

One effect of doing this, is that installing files is now EXTREMELY slow, and the installer irsetup.exe runs at 100% CPU.

So I'm wondering if the installer is parsing the entire Lua script each file? Surely not? Why does putting actions in unrelated stages affect the INSTALL_STAGE_INSTALLING_FILES stage?

Actually ideally the framework would allow this - allow us to do stuff that we can show in the progress dialog of the main "While installing" screen.

Splitting out each stage into its own event would be great, and have another event you call between each stage. E.g. instead of having just On Progress, you would have

OnPreparing
OnPostPreparing
OnInstallingFiles
OnPostInstallingFiles
OnCreatingUninstaller
OnPostCreatingUninstaller
OnCreatingShortcuts
OnPostCreatingShortcuts

events.

how 'bout it?

[Ulrich]

Hello,

while I understand what you wanted to achieve, your approach will not work as you expect. The On Progress event is a callback, fired by several actions, so your script will be executed several times. Even if you place tests to verify at which stage the installer is currently performing actions (for example, INSTALL_STAGE_CREATING_SHORTCUTS), this part of the script will still be executed for each shortcut you are creating. In your case, you say that you edit the registry... well, you probably are editing the registry repeatedly, each time new shortcut is created.

The Progress screen should be a reflection to what happens in your installer, and should be used to give visual feedback, instead of using it to perform additional actions. In other words, the screen should be driven by the installer, while you try to drive the installer with the screen. You should use the screen to show display some message, advance the progress bar, and allow the installer to resume its operation quickly.

So, what could you do instead? For example, you could add one or two additional screens where you perform your tasks. You say that you install/start/stop services. You could include a screen with progress bars, and advance them as needed. You could use one bar to show the total progress (service 1 of n installed/started/stopped), the second bar could be controlled by a timer, and show some activity while the setup is working in the background, waiting for the service to respond to the request. The user would have some visual feedback, and would know that the installer didn't freeze.

We added your suggestion for additional install stages to the database, the entry received the number 18803.

Ulrich

[adrien]

Hi Ulrich

Thanks for your reply.

I actually used a couple of global variables to make sure each section was executed only once, but it's still slow. I saw that some stages were called many times.

So I was wondering if it might be something to do with the way the script is loaded / executed in the lua runtime. I've actually embedded lua in a C++ app before. Obviously the same runtime must be used for the entire installation, else globals wouldn't work, but you're not loading the script more than once perchance?

Might it be quicker if I took all the say registry code (about 400 lines) out and put it in a global function instead?

I'm a bit reluctant to add other screens although that's the obvious solution if we can't get it working any other way, since then there would be several progress screens that we move through.

Thanks

Adrien

[Ulrich]

Hello,

I definitely would add a few screens, as in my opinion this would be best way to avoid problems.

Ulrich

[adrien]

Hi Ulrich

we moved the work out to a few function calls. This sped it up immensely.

So I can only conclude that the script is being loaded each event, rather than just loaded once and called for each event.

Then of course I ran into the problem of what if it's a silent install no dialogs, no actions.

Anyway, so we got around that one too.

I'm just now working on installing an NDIS6 LWF driver... do you get many customers asking for installs for that? If so, it might be worth me writing a component / SF extension for it.