The hidden performance hit when using Get Methods

There are many ways to write a loop when using C#. But when iterating you need to be very much aware of the data you are iterating. If you are not being taking good enough care of your code you may suffer from bad performance. For example when using a property like this property public static List<string> Strings { get { Console.WriteLine("GET"); return new List<string> { "1", "2" }; } } Then you will get completely different results when using one of the following three methods to iterate the items for (int i = 0; i < Strings.Count; i++) { Console.WriteLine(Strings[i]); } For this example the list will be retrieved twice for each iteration of the items. The first problem here is the usage in i < Strings.Count, which for each iteration will retrieve the list and count the items. Then furthermore in Strings[i] the list will be retrieved once again. var l = Strings.Count; for (int i = 0; i < l; i++) { Console.WriteLine(Strings[i]); } This is a slightly better solution, where the length of the list is stored locally and thus preventing the recount for each iteration. Still foreach Strings[i] the list is retrieved, so the implementation is still a bad solution. var temp = Strings; for (int i = 0; i < temp.Count; i++) { Console.WriteLine(temp[i]); } This is again a better solution, where the entire list is stored locally and thus the list is retrieved only once and then the local copy is used for each iteration. When doing this you no longer need to worry about the implementation and performance of the get method, as it is only used once. foreach (string s in Strings) { Console.WriteLine(s); } Another solution if you need to iterate all the items, then you can just follow this example which simplifies the code and prevents you from having to store the list locally. The effect is the same as the previous example just without the boilerplate code. So this should just serve as an example to watch you when using get methods that you do not control. 

InvalidOperationException when setting track properties from a BackgroundAgent on Windows Phone

This is just a feature that I stumbled upon when I was updating my radio app I wanted to add an enhancement, so that when the radio was playing I wanted to display the current song on the lock screen (UVC). This should be very simple and just a matter of setting the information on the current track. So back in Visual Studio I wrote the following code: BackgroundAudioPlayer.Instance.Track.BeginEdit(); BackgroundAudioPlayer.Instance.Track.Artist = "Artist"; BackgroundAudioPlayer.Instance.Track.Title = "Title"; BackgroundAudioPlayer.Instance.Track.EndEdit(); And this all compiled fine enough. But when I started retesting my app, I got an InvalidOperationException, which seemed quite curious. After a bit of googling though I found the answer, which was actually quite simple. For some reason when you call BackgroundAudioPlayer.Instance.Track you do not always get the same object (at least not when doing it from a BackgroundAgent), so in effect that means, that when you call BeginEdit, you do that on one object, but then when you try setting the artist you get another object, which is not in edit mode and therefore the invalidoperation exception. Solving it was fairly easy and just required copying the current track to a local variable and working on it there, and then everything is running smoothly. So my code ended up like this and the problem was solved: var track = BackgroundAudioPlayer.Instance.Track; track.BeginEdit(); track.Artist = "Artist"; track.Title = "Title"; track.EndEdit();