In a test in last month's 'sprint' we tested an emitted-code version of our business logic layer which currently uses reflection. On an enormous dataset, we got an operation that took 52 seconds, down to 2 seconds.

Emitted code is immense.

Cool. Apparently a lot of the base classes use emitted code for dynamic operations, like data binding and such.

Do you know whether lots of event handlers are a bad thing? Like, if I've got business objects with 20 properties each, would it be better to have a PropertyChanging event for each property, or one for the entire business object and the handling method does conditionals? Obviously the events would be exposed by the containing collections rather than the individual business objects, cos some of them can have hundreds of records and you don't want twenty thousand event handlers. I'm leaning towards separate events for each property.

Got a huge performance increase today by sticking individual data access routines in ThreadPool.QueueUserWorkItem calls. Be even better when ParallelFX gets released...

Odd you should mention that about the events. During our tests with the emitted code, we noticed that some events were being thrown about 25 million times, something we've not really done any analysis on before. Even so, with all those events flying, we saw that 50 sec reduction on a 52 second operation.

I'll let you know more if I can, once we've finished testing.