Monday, November 20, 2006

Localisation with VS2005 will slow you down

In my previous blog about a localisation that went sour, I mentioned that the time for building a localised application takes longer and longer for every language that is added. I have now quantified my feeling and found out that adding a language adds 15-20 seconds for each language. Now that doesn't sound that bad right? Wrong, If you develop an application that takes one minute to build and adding languages almost triples that time, then it becomes tedious very quickly.

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)
If a normal developer compiles 10 times an hour to test something, he/she will waste 12 minutes, just sitting to wait for VS2005 to build. I meanthat is an outrageous extra time, and I wonder if we can send a invoice to Microsoft for those hours that we just wait for the build complete? And I guess we have to make the work day longer as we get much less done.

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.

Measurement notes:
  • 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


Payton Byrd said...

Have you attempted this on a local directory? Dynamic folders in Clear Case are slow, especially over a WAN. You can use shadow folders instead and get much better performance.

Are you sure you're following Microsoft's best practices? I have always been told by people from MS that localized resource files go in their own DLL and as such are not subject to be rebuilt except when they change.

redsolo said...

I assume that the build will be quicker if I copy it to the harddrive. But that isnt the point of my blog as it shows what could happen if localisation isnt done properly and if the developers are lazy and use the VS2005 GUI way. In the begining they probably liked doing it using VS2005 as the job got done quicker, but now they are seeing the effects of laziness. So VS2005 is somewhat part of the problem. I wouldnt have done it that way, but this project has been ongoing for many years.

I assume that it would be better to put everything in a satellite assembly. But that would require updating every form with new localisation keys, testing, etc. They are now reluctant on doing major changes as they did have some problems when going to VS2005 and .NET 2.0.

Payton Byrd said...

I don't know how familiar you are with Clear Case, but it gives you two ways to use it:

1) Dynamic volumes - which is what your client is using
2) Mirror volumes - which work the same way that most other source control systems work.

If your client is really that concerned with performance, they should go with Mirror volumes.

As for the satellite assemblies, again, if they are that concerned with performance then they should take the time to do it right. Putting multiple resource files in the main project is not, and never will be a good idea. They should load the appropriate assembly via reflection which will also greatly reduce the overhead of the primary executable. I don't think they should have to change any localization keys. Perhaps they should spend a day just creating an abstraction for localization that makes the referenced assemblies look like the local resource files to the application at runtime.

This isn't a VS 2005 problem, this is a user-error problem. You cannot blame VS 2005 any more for someone shooting themself in the foot than you can blame a Glok 9mm for someone shooting themself in the foot!

Ondrej Medek said...

Yeah, it's VS 2005 and Microsoft problem. Since they write a tool, recommend it. It works fine for a small projects, but not for larger ones. There should be a possibility to share common resources in Form Designer. I.E. to set something like button1.Text = Properties.Resources.TextOK