A follow up to "A Short Tale of a Deceptively Slow LINQ Expression"
The inimitable Ian Griffiths left a great comment on my last post – saying that:
You seem to be implying that the LINQ query was being evaluated each time round in "the outer foreach". But I don't think that's right. A foreach loop evaluates its collection expression just once at the start of the loop. It was only the call to Count() inside the loop that was causing multiple evaluations.
Reading the post again – he's absolutely correct – the 2nd code sample was just a snipped I pasted into a draft email as I was doing some performance profiling and by pulling out the files variable from the foreach loop – I'm insinuating that there is a performance penalty there. The reason I did pull out the files variable was I was just checking to see if it was being re-evaluated as the variable was derived from C# 4.0's IEnumerable<string> support in System.IO.File, which allows lazy evaluation of file / directory searches and allows your to yield results rather than maintaining the whole directory / file structure in memory. By pulling the variable out and forcing evaluation – I was just checking what the performance profile was like.
John Sharratt also left a comment with a link to Rob Henry's excellent blog post about removing the repetition and ceremony around event firing using generics.
The code snippet I posted was not actually the final implementation I used for Templify. I introduced some further performance tweaks (parallelization) and also conventionalised progress notification.
I would highly recommend purchasing Ian & (fellow endjineer) Matthew's rather excellent Programming C# 4.0 book – you'll start to get an insight into how insanely bright these two guys are and how much wonderful knowledge you were missing about the .NET Framework – you will definitely be working smarter…
