Visual Studio Slowdown with ORM

[Brian Azzi]

Hello...

So I've run into a frustrating problem with the latest release (honestly not sure if it did this with the previous release or not).

I have installed the OpenAccess ORM software using the Telerik control panel & VS2010 integration. I am using the ORM controls on a new project and it is working fine.

What I've found is that if I now open my other main project (which is much larger and does NOT use ORM), the VS IDE gets EXTREMELY slow when right clicking for a context menu in the solution explorer. (5-6 seconds for the menu to come up!!!). 

I uninstalled & cleaned out all Telerik products & the project opened and ran fine with a normal context menu. I then added things back one at a time and found that the ORM product was the one causing the slowdown.

I tried to disable the add-on in the tools menu, but this didn't seem to help things at all... (It was still slow until I completely uninstalled OpenAccess). 

Any advice would be appreciated! I really do like OA and want to keep using it, but as it is now it's making my main work project miserable.

Thanks,
-Brian

[Alexander]

Hello Brian,

This is the first report for such a problem, so I will have to ask you a few additional questions in order to narrow down the possible causes of the issue.

OpenAccess integrates in Visual Studio using an add-in and a VS package. The add-in is mainly used to include the OpenAccess menu within the main Telerik menu and in the project context menu. The package on the other hand provides the visual designer, its wizards and all project and item templates. It also loads additional commands in some of the menus. You said that disabling the add-in has no apparent effect on this behavior, so most likely the problem is in one of the package commands.

The package provides only one command to the project's context menu - the one for running the Add OpenAccess Service wizard, so this is the first thing you could try disabling. Close Visual Studio, open the C:\Program Files (x86)\Telerik\OpenAccess ORM\dsl2010\Extensibility directory, cut and move the Dsw folder out of Extensibility. Start Visual Studio and test if the context menu is still slow. This will completely disable the AOS wizard but you could always get it back by returning the Dsw folder to its original place.

Besides the test above, please also check if the menu opens slowly on any kind of an item in Solution Explorer or only on some types - solution, project, folder, code file, etc. It would be helpful if you could also describe the type and the structure of your big project - how many files and folders it contains, so we could try similar setup on our side and hopefully be able to reproduce the slow-down.

Thank you in advance for your assistance and please excuse us for the inconvenience caused.

Regards,
Alexander
the Telerik team

[Brian Azzi]

Hi Alexander, 

Thanks a ton for your response. Here are the results of some further testing I did based on your suggestions:

• Removing just the Dsw folder out did not seem to make any difference.
• If I move the entire Extensibility directory out, I get an error on opening VS (DslPackage.EntityDiagramsPage.10 did not load correctly), but my context menus all speed up to normal performance (no delay). (Oddly removing the other folder in the extensibility folder didn't do anything either... i had to move the whole extensibiltiy folder).

• The project itself has about 500 files (more if you include the documentation sub-directory). It probably has around 30 or so folders. Also keep in mind that number includes lots of generator type files & config files. 
• The solution has several sub-projects... with 2 or 3 installer projects, a web application, and a code library project.
• The context menu slowdown only seems to effect source files (aspx, js, images, etc). Right clicking on a folder, project, or solution seems to be "ok". it's just the content files that are extremely slow (6-7 seconds slow).

As I said, this solution does not use OA at all. I do also use Telerik JustCode, though in my tests I made sure all its processing was done prior to trying any context menus, etc.  

I am also using a perforce source control solution that can typically be a little slow at times... but again, with the folder moving technique above I can verify that the speed is fine when the OA piece is turned off.

Please let me know if you'd like me to try anything further / have more suggestions!

Thanks!
-Brian

[Alexander]

Hi Brian,

Thank you for your effort and the additional information. It seems the problem is deeper in the package itself, not in the AOS wizard.
At this stage we will need more time to reproduce and investigate the issue. At least now you know how to disable the package without uninstalling the whole product. We will let you know in this thread when we have more information on the matter.

Kind regards,
Alexander
the Telerik team

[Brian Azzi]

Thanks again. Yes, being able to turn it off without uninstalling is useful... but it doesn't really help me since I need it on for one project but not the other (I often have both open at the same time as I am actively developing both applications). 

At any rate, hopefully it will be something that can be fixed or optimized. : )

[Alexander]

Hello Brian,

We tried different setups but unfortunately we were not able to reproduce the slow-down. Perhaps it is not only the size but something else specific to your project that causes the problem.

If possible, please send us your project in a support ticket (you will not be able to attach files in the forums), so we can see if it behaves the same way on our side and investigate it further. It is not necessary the project to be compilable, we need it only in design-time.

Regards,
Alexander
the Telerik team

[Brian Azzi]

Hi Alexander,

I'm just getting back to this issue now (sorry for the delay). Unfortunately, the project where I see this problem contains lots & lots of proprietary code so I cannot send the whole thing. I'll see if I can create a smaller solution with similar results... but I'm definitly still seeing the issue. Uninstalling the ORM product or running VS2010 in /SafeMode makes things work fine. 

Do you know of a way in VS to disable a particular extension package on a per-pkg basis? 

Thanks,
-Brian

[Brian Azzi]

Ok... some additional information for you:

I have actually narrowed the problem down to one directory. I have my project setup to include all of the files from a "Docs" directory that is published by a documentation group. Visual Studio is setup to automatically include all files in this file at runtime (rather than have hard coded references to these files). This directory contains 2,513 files in 48 sub-directories (it is auto generated web based help that can change quite frequently but is needed in the project for setup purposes). 

This was done by editing the project file (I found this on a MS VS site):

<!-- include all files in the docs folder -->
<Content Include="Docs\**\*.*" />

I have had no problems at all with this project until I installed the ORM package.

-Brian

[Alexander]

Hello Brian,

Thank you for the additional information, we were able to reproduce the slowdown by including a folder with many files in the project. We will investigate the problem in more details and let you know our findings.

Regards,
Alexander
Telerik

[Alexander]

Hi Brian,

I am glad to notify you that the problem has been fixed. It was related to a check for available Entity Framework or Linq To Sql models, which can be converted to an OpenAccess domain model. This check is now optimized and should not degrade the performance of Visual Studio.

This fix will be part of the first service pack after Q2 2013. Unfortunately it is too late to include it in the official Q2 build, expected later this week. Thank you again for reporting this issue, your Telerik points have been updated.

Regards,
Alexander
Telerik

[Brian Azzi]

Excellent news, thanks again! I'm ok for now as I have simply excluded the directory in question for the time being (it is not critical to have in for everyday development, but is needed by our build system). 

-Brian