Hah, we've all done it, having the strategy to not fully "trust" yourself and do stuff like profiling or writing tests is the redemption.. right?

Only human after all ;)

been there, done that, fixed it, and had it blow up on low end machines because of garbage collection. good to know the unsleeping one is also human. (chapter 6 is good; still working on it)

Almost like grabbing a new collection from the DB on every loop.

At least you caught it early, and like Stephen says doing the profiling and testing is the redemption. =)

Worked on a project (well before I knew / understood testing etc) that was supposed to rendered an image map if the number of datapoints was less than 100 (some images would have 800 or more datapoints). The code should have been if() { foreach() } but was foreach(){ if() {} } - and went to production that way.

Suffice to say clients were complaining of slow page times in very short order. * very embarrassed developer *

So, can anyone tell me what's happening here?

What tool these screenshots are from?

I love your blog, but sometimes you leave us mere mortals confused and dumbfounded. Could we have a few lines of explanation, so that we can try to keep up!

Yeah, he likes to keep us in the dark. I've seen that rethorical mechanism quite a bit on diary blogs as well ;).

Like the other bits of life are too easy.

The delegate for the NotifyOnChange also walks over all urls, which the outer foreach was also doing.

In the second shot, the iteration is taken outside the foreach loop which should speed up things quite nicely.

But then I'm probably wrong.

Cheers

Screenshots -> JetBrains dotTrace

engine.Cache.Whatever -> LoD?

looks like winmerge/diff to me, but i might be wrong.

anyway, there is a seemingly costly call to some engine.Storage.Nofier within a foreach loop. while it seems to have been better doing this only once, after the foreach.

but without knowing the context, this could be perfectly valid or hell breaking loose.

can someone what this is all about...