Concrete base Command causes Experimental Instance to take minutes to update Tools menu
LeeMSilver opened this issue · comments
My extension has 80+ commands that all derive from a common base (B) which in turn derives from Command.
When B is abstract the Experimental Instance's (EI) Tools-menu is updated with the Extension's commands in < 30 seconds - not real fast, but acceptable.
But when B is concrete, the Tools-menu was not updated aftermore than 5 minutes (at which time I closed the EI). The Output-window in the main VS session was continuously pausing and then deleting groups of threads.
This happened repeatedly and when I alternated between concrete and abstract the timings were as I described above (unusable for concrete and acceptable for abstract).
Ordinarily this would only be an annoyance with a warning not to use a concrete base class; but in my case it's a bit more serious. I wanted to use to use B to do the Extension's Dependency Injections (DI); but since it can't be concrete for a meaningful Debug experience I had to create a non-invocable class to handle the DI's.
Is the common base class being concrete/abstract the only difference between the two tested scenarios?
In other words, if you take your code with the concrete class and you only make the change to mark that class as abstract (you don't add any abstract methods, just mark the class as abstract), does that make your extension faster?
So, my question is, now that you have it concrete, if you make it abstract again by only adding the abstract keyword, does that alone improve performance? The title of this issue would suggest that that is the case. But I would like to have confirmation since it may have been one of the other changes you described above that had unexpected consequences.
This is all my bad. Note that I deleted my previous comment as it was totally inaccurate.
Somehow I thought that making my base class concrete I could eliminate my DependencyInjectionCommand and do the dependency injection (DE) in the base class. I had a brain-fart and forgot that I would have to change the signatures of all my *Command classes to include the DE parameters that would now be in the base-class signature.
So I will continue to do the DE in the non-invocable DependencyInjectionCommand and be thankful that all *Command class constructors run when the first command is invoked.
Thanks for your assistance.
You can close this as a user error.