Generating objects - use more than one thread

[halotron]

It takes a considerable time to serialize some objects graphs. It would be nice if the serialization could be paralellized.

[OmarElabd]

@halotron that's a very good idea to have multiple threads work to serialize the child objects. It certainly is a task that seems like it can be parallelized, but since the object that i use to serialize is a com object taken from the visual studio debugger there may be some issues with running multiple threads. I'll have to investigate and see if it's possible.

Are you running object exporter on large objects with a deep hierarchy?

[halotron]

Ok. Well I capped it to level 2 and had to abort it since it took too long to complete. They are not very complex EF-objects with some lazy loading going on I think. I cant really switch lazy loading off just for serialization. But since the load was 100% on one core only I guessed there could be room for some paralellization.

[Pecral]

@OmarElabd Do you think that the performance is related to the usage of the Env.DTE expression interface instead of the IDebugProperty2/3 mentioned in #46?

I'm currently working on a project which uses the Env.DTE expression too and I've got some performance problems as well as problems in separating the expensive work into a second thread so that my interface doesn't get blocked. I've never worked very much with COM-objects though, that could be the problem.

[OmarElabd]

Hey @Pecral, I'm not sure if switching to IDebugProperty will significantly affect performance since they are both com objects. I would recommend creating C# objects from values retrieved from the Env.DTE or IDebugProperty com objects (might need to set a depth max). Constructing the C# objects can probably be parallelized using more than one or two threads. Once you have representative C# objects, you should be good. This is the approach I am taking for v2.

[Pecral]

Hey @OmarElabd, yes you're right, that's the way my extension works currently. Once the representative C# objects are created, the performance is fine because the data is cached. The problem occurs when querying 100+ expressions plus their child-expressions (i.e. a large list of complex objects), which has to happen in one feature of my program. My attempts at parallelization as well as preventing that the GUI gets blocked weren't successfull yet. I'm excited to see how it'll work out for you! I guess the latter isn't really a problem for you though (I think in the current version the wait-window just gets a bit laggy).