Improving performance when a large portion of data matches a workflow activity criterion

Here is a real customer scenario from a related Support Center thread: 

"Hi, I have an application with several workflows that work ok in my local computer (testing with few records), but when I deploy the workflows to a server and the workflow gets approximately 1,500,000 records that match the criteria the workflow service crashes...

I've done some testing and this only happens when the workflow needs to deal with a lot of data, workflows that deal with less records don't have a problem. I've been looking for an alternative like XPCursor or something similar to ask the workflow to page the records that meet the criteria but I haven't found any."

After some time, we could replicate this behavior locally and found that it could be easily improved upon on our side. In short, our solution is in using XafDataView + a sort of paging  when first querying and processing records that match a certain workflow activity definition criteria in the workflow service. 

About profiling memory leaks...

I want to pay your attention to this Support Center ticket, because here I was involved in memory profiling with my colleague, and also because I remember that some time ago somebody from the XAF community asked to elaborate more on the memory profiling process. 

I doubt this info will be interesting for experienced developers, but we should not forget that there is a large number of people who are using XAF and who love it because it helps them to care less about the underlying technology and what happens behind the scenes.

Hence, my colleague and I wrote a detailed explanation of how we profiled a case when a report preview window is opened and then closed. So, let me quote us from that ticket:

"In fact, it is not guaranteed that the CG will be called automatically after a period of time.
During the normal application life cycle, GC may not be called at all, unless its garbage collection is forced by the CLR.
You can learn more on how the GC works at http://msdn.microsoft.com/en-us/library/ee787088.aspx#conditions_for_a_garbage_collection.

Now please let me elaborate on how we find memory leaks in .NET apps internally.
For example, you may want to check for memory leaks when a report preview is shown.

Here are the steps you would perform: