views:

36

answers:

3

I have a WIX 3.0 installer that is building 88 slightly different builds (cross product of 32 and 64-bit, 11 locales, four editions (Beta, Retail, Evaluation, Different Evaluation).

Each build has slightly different contents in addition to localized UI, so I can't just build one configuration with multiple locales.

The resulting MSI is about 120MB. I'm already using the CabCache.

The installer takes about 3-5 minutes per release to build, resulting in a pretty lengthy overall build time.

The install appears to be heavily disk bound during linking (light.exe).

Clearly making the disks faster could help. Does anybody have advice on how to set up a machine that could crank through these installers faster? (or advice on reconfiguring my WIX project to build more efficiently?)

A: 

Get an SSD. Like one of those with internal RAID architecture from e.g. OCZ. SSD is every developer's upgrade of the decade. Plus more RAM if swapping is an issue.

Ondrej Tucny
I have yet to read a compelling argument for SSDs with compiling and linking as the target to speed up. I see lots of talk of applications loading faster. But nothing about speeding up compiles. In fact, most people say it makes little to no difference for compile time. Do you have experience that contradicts these findings?
Brian Gillespie
A: 

If you have common parts (that are not localized) you can create a merge module with the common parts and then just add the differencing stuff to each build.

Albin Sunnanbo
Thanks for the idea. It's funny I didn't consider that... I have merge modules for the things things that are different. It didn't occur to me that making a merge module for the common files would make any difference at all. Since it's going to take some rearrangement to do this, I'll ask: have you actually seen a difference at link time by using merge modules. I can imagine it working, I can also imagine it being a wash, depending on implementation.
Brian Gillespie
It looks like Rob Mensching recommends using .wixlib files when using WIX instead of using Merge Modules. Perhaps I'll try that first: http://robmensching.com/blog/posts/2008/10/10/What-are-.wixlibs-and-why-would-you-use-them
Brian Gillespie
@Brian: It was a couple of years ago I did that, it was mostly to make the wxs-files easier to maintain. I don't remember what the performance impact was, sorry.
Albin Sunnanbo
A: 

I am not sure if you have any say or communication with the developers of the application that you are installing, but if you have to create that many MSI's mainly because of languages, have you considered just offering one Language MSI that delivers all the language specific files to a resources directory and then the user can choose which language they would like to use (but only install this if they need something other than the default language). Also it might be worth looking into having the product made in such a way that the user can pick from within which language is best, then having all the languages installed from the start.

As for your question about speeding up the build, that is a tricky one. Using Merge Modules I would rule out right away, as I don't see any actual gain coming out of that. Of course updating the hardware (as you said) will give some results, but again, I am not sure how much of a jump you would be making so it is hard to tell what kind of gain that would give. I think it might be best to go over your WXS with a fine tooth comb and see what is really going on in there. You can sometimes find things that are left over from the developement of the package, or from a previous tool that are really slowing you down. One example would be that my company recently switched to WiX from a more automated setup creation utility (leaving the name out on purpose cause I am listing the problems with it :P ) and it automatically created every folder under Windows that might possibly be needed in the running of a windows application, as well as the common files folder, the current user profile, and many many more. I think I ended up erasing in all over 100 empty directories that this old technology was nice enough to add for me. That is just one example of optimization that was done. It is amazing what can be found when you take the time to REALLY review what is going on under the hood.

Adkins
@Adkins, Thanks for thinking about this. Unfortunately, the language-specific components are about 50MB per language. Installing all of them (even when most people don't need most of them) would result in an extra 500MB of download size - thus the differentiation. So, for Beta, Evaluation, and internal test versions of Retail, the size is significant. However, for retail product distributed on CD, we do offer users the choice at install and runtime which languages to use. Also, based on feedback I've gotten from WIX developers, using merge modules actually makes the linking performance worse.
Brian Gillespie