Description:
If you create a page with a lot of components, Visual Studio performance is extremely slow if the Designer is enabled. DevExpress components in Classic render mode render HTML 'table' tags. Visual Studio utilizes an IE-based internal browser for rendering the design view, but IE renders tables rather slowly. If any control's property is changed, the layout is rendered again, which results in poor performance.
Please note that there is another issue that looks very similar to this one:
Saving an ASP.NET page at design time is very slow in Visual Studio 2012 (2010)
However, the sources of these issues are absolutely different. Sometimes they can appear together when you are editing a page and you can think that this the same issue. It is important to clearly understand what issue you have encountered, because there are different solutions/workarounds to them.
If you see the following behavior:
- Visual Studio hangs for a while only when you are changing page or control settings in Design or Split view (even if you are using the Properties window to change the settings);
- but all operates fast if you are editing Page/UserControl markup and no Design or Split view is shown;
This means that you encountered the issue described in this article. Please refer to the Solution section and try the suggested approach.
If Visual Studio hangs only when you are saving a file (please note that Visual Studio automatically saves all changed files when you compile a project) and this occurs always no matter whether you open a page either in Design or Split view, or directly editing page markup, this means that you faced another issue, described in the Saving an ASP.NET page at design time is very slow in Visual Studio 2012 (2010) article.
Answer:
We fixed this issue in versions 17.2.10, 18.1.5 and higher. See Visual Studio 2017 performance is slow if a complex page with numerous editors is saved on the Source view for details. The hotfixes will be available this week. Please let me know how the fix works in your applications.
For previous verions, use the following workarounds:
To solve this issue separate a page layout into several UserControls. For example, if you have ASPxPageControl, ASPxPopupControl, ASPxLayoutControl, ASPxPanel, etc., that contains a dozen of editors or several ASPxGridViews, it is necessary to create a UserControl, move the contained elements there, and put the UserControl on the page. Visual Studio does not re-render UserControls every time a parent page is modified. If you need to change controls encapsulated in the UserControl, open it and modify. Changes will be automatically displayed on the parent page.
There are several other advantages of this solution.
- The page ASP.NET markup becomes less. This will be very helpful in the future after a couple of months if you need to analyze a current page structure and change it according to new requirements (just personal experience).
- Sometimes several pages have the same layout (in part). For example, Sign-in and Account pages contain such editors like First/Middle/Last Names, Email, Password, etc. The described approach allows you to use the same UserControl (with the corresponding internal logic) on different pages. This makes your application a bit more flexible.
Please refer to the Slow Design time to code switching in Visual Studio 2010 (with SP1) ticket that contains samples of problematic and updated projects.
See Also:
Saving an ASP.NET page at design time is very slow in Visual Studio 2012 (2010)
The following solution was found by one of our customers.
When I start VS2012 with administrator rights, then everything works without any problems.
The following two links have helped me:
http://social.msdn.microsoft.com/Forums/windowsapps/en-US/be50be61-39eb-49ba-aaf5-b18ded17c107/vs-2012-switching-to-design-mode-is-very-very-very-slow
http://blogs.msdn.com/b/abhiann/archive/2013/02/14/always-run-visual-studio-2012-as-administrator-in-windows-8.aspx
Paul Usher provided this workaround in the ASP page saving / upadting is very slow with DevExpress controls ticket.
One workaround for this problem that does not require the additional work of user controls is to edit the code only, NOT using the split (source|design) screen. You don't need the designer window open in Visual Studio at all. To see changes you are making in the markup almost instantly, simply run up a copy of the web application, when the browser has your pages displayed, stop the application from running. This still leaves the instance if IIS Express running still serving up the web page. When you make changes to the markup, CTRL+S (or file, save) is instant, and then a refresh on the browser page renders the new page layout almost instantly (depending on your data bindings).
Other things to note, in my tests I am running VS2012 with Update 4, and I also tested on VS2013. I was able to get the same speed and performance on my testing VM (running on 4gb ram on laptop) as I did on my main dev machine.
Thanks Vladimir. The joys of Visual Studio!
I had the problem when using a DX 12.2 templated webproject, with master-pages.
there were only a few pages, containing a few simple controls.
moving the registration tags to the pages didn't succeed.
opening VS as administrator didn't change the problem.
i just cleaned up the tens of needless dll references which were added by the template, now the designer works smoothly…
a possible solution if you can drop those references.
Thanks Joris,
That solved the problem for me, i had just to much unused references, just like you
Which DLLs did you clean up and where were they located?
The solution posted by Joris also greatly improved this problem for me, though it's not totally gone.
Thanks, Joris.
Is there ever going to be a proper solution for this?
I've now stopped using the Devex controls completely.
I should actually get a refund for the money I paid for these controls.
Hello Daniel,
Unfortunately, no. Visual Studio designer ineffectively draws controls. This is true for all ASP.NET controls, including default controls. Since our controls reflect their appearance at design time in a very detailed manner (and as a result, they are more complex), this makes the issue more noticeable.
I suggest you always separate a complex page into several User Controls. This will greatly reduce the effect of this issue and facilitate further maintenance of the code. If you wish, you can send me the problematic project and I will demonstrate this technique in the context of your scenario.
An alternative solution is the use of a browser to review the result of the changes. Since ASP.NET applications usually apply ASPx markup changes on-the-fly, this solution seems to be effective. All you need to do is make changes without using the designer, save them and refresh the browser tab where this page is opened online. Please refer to my main post that describes possible workarounds in detail.
For what it's worth, this was causing huge pain this week with a large page that could not be made into a User Control as suggested because it was just a single FormLayout with many records.
My solution was to remove the "Apply Styles" window that I normally keep open with the Toolbox tab. Note: I had to restart VS as well afterwards to get the benefit.
Hello,
To process your recent post more efficiently, I created a separate ticket on your behalf: T203126: A page design time performance is slow if the page contains an ASPxFormLayout with numerous fields. This ticket is currently in our processing queue. Our team will address it as soon as we have any updates.
I also built a rather large, complex form and had to split it into multiple user controls which was certainly easier to manage, but even then just provides more of a headache than the ease of use that this control promised. I too am considering disposing of this control, it's quite the headache.
Hello,
To process your recent post more efficiently, I created a separate ticket on your behalf: T247331: A page design time performance is slow if the page contains a lot of controls. This ticket is currently in our processing queue. Our team will address it soon.
So now we're up to Visual Studio 2017 and the Devexpress controls are as slow as ever when working in the Designer.
At the moment, each time I change something in the HTML code, it takes about 45 seconds for the page to "refresh" before I can work again.
My PC is an i7, 7th generation with 32GB of RAM, SSD hard drive.
I've made a little video so prospective Devexpress users can see what they are in for.
(Sorry it's in swf. I recorded it in Jing.)
Hello,
I've created a separate ticket on your behalf (T581690: Visual Studio 2017 performance is slow if a complex page with numerous editors is opened on the Design view). It has been placed in our processing queue and will be answered shortly.
Completely agrees with Daniel Gochin, DevExpress controls are now so slow that it seems I spend half of my working day looking at some kind of hours glass etc whenever making any kind of change to a page using DevExpress controls. This is getting unbearable and we have started to consider our options.
Here is my input…
I am working on a brand new HP Z8 , Intel Xeon Gold 5120, 28 cores, 56 logical processors, 36 GB servergrade memory…
… and my rather simple page is crawling up in the designer.
My direct point to you guys at DevExpress, you are having a growing issue of slow performance when your customers are developing.
It seems to me that the FormLayout is the main cause for this slowness. This has been so for many years now, so it is quite clear that this is a known issue.
… and then the question pointed at Devexpress is: Can you do something about this?
Hi Sigthor,
We seem to have found the cause of this issue. Currently, our R&D team is testing potential solutions on different page layouts. Would you please share your problematic page with me?
Here is a page with very slow Performance when is opened in Designer
Hello,
I've created a separate ticket on your behalf (T655717: Slow Performance when is opened in Designer). It has been placed in our processing queue and will be answered shortly.
Hi all,
We have fixed this issue in versions 17.2.10, 18.1.5 and higher. See Visual Studio 2017 performance is slow if a complex page with numerous editors is saved on the Source view for details. The hotfixes will be available this week. Please let me know how the fix works in your applications.
Vladimir, great work!
On the first view, it look very much faster with HotFix 18.1.4.18207. This will save much Development time.
I will look in Version 18.1.5, too.
Thank you for your feedback, Dirk! I am happy to hear that the fix works.
Let me know if you face any issue after upgrading to v18.1.5.
I just wanted to say thank you for this fix.
I've been using your controls for 7 years now and the design view slowness was always a major frustration. Sometimes 20 to 30 seconds to change the ID on a text box.
I found setting properties, locating controls and other functions easier in the design view especially when I have a large number of controls.
I loaded one of my notoriously slow pages with 18.1.5 and there is absolutely no delay when viewing or changing properties.
My cardiovascular system thanks you.
Nic
I am really happy to hear that the fix helps, Nic. I'm forwarding your cardiovascular system thanks to our developers. :)
Should the issue appear in some specific scenario, feel free to contact me at any time.