I notice the installer created by InstallBuilder installs really slowly for large software especially on Windows platform. (The data below are collected on Windows platform)

I have a main installer about 1.74GB in size, which also calls some sub-installers and unzips some big zip files. The total installation size (after installed) is 17.9GB, with 165529 files, 18763 folders. The total installation time is over 80 minutes. We had our existing installer, installs the same set of files in 28 minutes.

The installation is much slower than a 7z unzip. The installer created for 3.12GB, 54176 files, 11051 folders takes 19 minutes, while 7z only takes 6 min. I understand it can be slower than a zip tool, but shouldn't be that slow.

Also the "unzip" action provided in the InstallBuilder is much slower than an "unzip" tool. I have about 20 zip files in total 8.59GB, 13655 files, 47 folders. The installBuilder unzips them in 19 minutes, while a standalone unzip tool unzips them only in 6 minutes.

BTW, the installer is created unsing "zip" compression method. I'm not enabling the debugger. Also I'm using InstallBuilder for Qt 8.5.

Any suggestion I can use to improve the installation time?

Thanks.

asked 25 Sep '12, 21:44

gt8967884's gravatar image

gt8967884
116747678
accept rate: 12%


One of the reasons for longer time to install may be the GUI updates that show each file name.

Could you check if disabling indicating the unpacking progress speed up the installer?

<project> <showFileUnpackingProgress>0</showFileUnpackingProgress> ... </project>

Also, can you compare the time by running the installer in unattended mode - for example:

C> start /wait installer.exe --mode unattended

and measuring the time it takes to run it without GUI? That should help understand where the difference in installation time is coming from.

Regarding the <unzip> action, it is meant more as a helper action and may be slower than dedicated ZIP tools. Can you also try to package those files that were originally inside ZIP archives as part of the installer and see if it is making any difference, especially with <showFileUnpackingProgress> disabled?

If the installer size was to exceed 2GB, you can switch to CDROM mode documented in CDROM Installers section of our documentation and especially in Distributing big installers in other media formats section.

The How can I hide the unzip progress during install? question shows how to hide progress of unzipping the files as well - that may also speed up the unzip process.

link

answered 26 Sep '12, 10:00

wojciechka's gravatar image

wojciechka ♦♦
7.8k61122
accept rate: 26%

We've noticed an occasional problem with performance on Mac OSX as well. It only seems to affect a smaller portion of our user base, and the particular system we've been able to reproduce it on is running OSX 10.8.3. We have tested it on other systems running 10.6, 10.7, and 10.8, and it works fine. This doesn't affect Windows or Linux, but our Mac installer is considerably larger due to extra dependencies we need to ship.

We're using InstallBuilder 8.5.0, and we already have "showFileUnpackingProgress" set to 0. Here is some basic info about the installer contents:

Mac OSX: 600 MB, 13,000 files. Windows: 140 MB, 3,200 files. Linux: 170 MB, 3,800 files.

When we run our installer on the problematic system, it gets to the point where we have a progress bar for copying files to the machine. At that point, the installer either slows to a near stall, taking over three hours to complete, or locks up outright (a client literally left it all weekend and the progress bar only made it to 50%).

We tested unattended mode as suggested here, but that had the same problem. We then tested the installer running in text mode, and if finished just fine. So that does seem to indicate that it's a UI issue, and the reason why it affects the unattended mode is because that mode still brings up a progress bar. What's strange though is that this doesn't affect every Mac, just a few of them.

Any ideas if there is a workaround to this problem, other than running it in text mode?

Thanks!

Ryan

link

answered 21 Jun '13, 11:20

Ryan's gravatar image

Ryan
1112
accept rate: 0%

Your findings indicate a problem with the GUI mode (text mode didn't have problems).

I'm wondering, is your GUI running in qt mode or in osx mode? You can check the mode via the installer_ui_detail installer variable at installation runtime.

See http://installbuilder.bitrock.com/docs/installbuilder-userguide.html#built_in_variables and http://installbuilder.bitrock.com/docs/installbuilder-userguide.html#_selecting_the_execution_mode

(21 Jun '13, 12:59) Dirk Stegemann

This is printed in the bitrock_installer.log file, so I think it's in osx mode:

Preferred installation mode : osx

Trying to init installer in mode osx

Mode osx successfully initialized

(21 Jun '13, 13:07) Ryan

To see whether it makes any difference, I'd download the BitRock Qt installer, as it utilizes the Qt GUI framework.

(22 Jun '13, 04:27) Dirk Stegemann

I gave the Qt version a try, but still had the same problem. Strangely though, we found a workaround where if we had another window (ie: Finder) covering the progress bar in the installer UI, then the installer progressed as normal. So it seems the problem is specific to how the progress bar control is updated...

(24 Jun '13, 11:19) Ryan
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×3
×2
×1

Asked: 25 Sep '12, 21:44

Seen: 2,965 times

Last updated: 24 Jun '13, 11:19