This is what I found out (table and graph):
- Default language took 69 seconds to build
- With two languages it took 85 seconds to build (16 extra seconds)
- With four languages it took 118 seconds to build (49 extra seconds)
- With six languages it took 144 seconds to build (75 extra seconds)
For this project, the solution was to remove all language resource files from the project file. This means that the only language that is supported in mid-development is "default" and nothing else. So fixing those too narrow labels for localised texts has to wait for another day. The tool do add/remove all those languages to/from the project file is developed in house and can not be shared unfortunately. The tool is very simple to create, but in my view unnecessary.
Here we have a grave problem with the localisation in Visual Studio 2005. If it is done as MS wants, the build time to a project can (and probably will) go up for every language added. What is the outcome of that? Either the developer will stop adding localisations, constrain the development by only showing the default or sit and do nothing while the project builds. This is not a good solution. I would rather have a one-file seperate from the GUI, which reads on the fly when the application is started. That way the language files does not affect the build at all, and it will be a minor load time added for the user which probably will not be noticed.
- This is an observation of an application that has been under development for 3-4 years.
- They have tried to follow MS design guidelines.
- Clear case is used with dynamic views, which could have an impact on the result as it needs to access 200 new files for every added language.
- The application is not divided up into more than 2 GUI projects. Perhaps adding more sub projects could make the build quicker?
- I used a C# application to measure the time it took to execute a bat file containing "devenv app.sln /build debug"
- I measured each language addition at least 4 times