I realize that this question is quite old and the original author has probably long since made a decision. However, when I was personally directed by my company to use DevExpress and I was trying to eek out all of the performance that I could, a Google search would always point to this thread and many like it across the internet. There's always a question, a few anecdotal responses, and usually a PR response from somebody that works for DevExpress. I rarely find honest answers from experienced people.
In the past, I've used Telerik, Infragistic, and DevExpress. From a performance and maintenance perspective, DevExpress is the worst. All of their controls have odd properties and accessors that do not align with what somebody that is familiar with ASP.NET or even HTML would expect. Since the properties and accessors of the controls are so convoluted, you will find that you've written about twice as many lines of code that are necessary in a normal .NET application.
DevExpress controls are rendered out as hugely bloated, nested tables. Some controls expose a lightweight rendering mode that is better, but their styling and functionality do not match with the other DevExpress controls, and I found them to be quite buggy in cross-browser testing.
Custom styling requires many, many custom CSS selectors that force you to code DevExpress class names into your CSS, due to the nested and hidden nature of the control properties. This is very bad practice, since DevExpress can and should be able to change their internal CSS class names whenever they see fit.
These controls also make an absurd number of GET requests to their DXR.axd handler that serves up resources.
There's no doubt that their controls work fine in a Demo environment with only 1 control displayed on the screen, but in the real world, these controls are terrible and should be avoided. Implement your own controls or just download Bootstrap and use native ASP.NET controls. I replaced DevExpress with controls that I created that style the native HTML type that gets rendered from .NET and the following chart illustrates some of the differences in resource usage between the two. There were no changes to the page layout, business layer, data layer, or database code for this swap, just a replacement of DevExpress controls that I'd previously optimized and tried to squeeze every bit of performance out of with my own controls.
That's bad, but I wouldn't point straight at the DevExpress controls when assigning blame - I'd be running a profiler against my code to work out where the issue really is.
As a general rule, when designing for the web, try to keep your pages light so they can run faster. For example, do you absolutely need 20 controls on one page?
And if they do not need any special functionality then you can use the native rendering.
2016 - Over the last 5 years I have used Infragistics, Dev Express, Telerik in that order.
Infragistics I won't even get started on because it is a subject unto itself.
My biggest pet peeve with Dev Express is their controls do add some "bloat" to the overall result. However, some controls do have feature sets that are worthy of the bloat. Certainly their Grid and Pivot grid are complex tools that allow the user to do many things, and i have successfully implemented Devexpress packages that worked both quickly with very good results. I have two problems with Dev Express:
Every time I install a new version, it breaks a significant amount of code, that's both WebForms and MVC implementations. That is quite frustrating, but as programmers to be expected I guess.
They really don't look very nice, you have to go through significant effort to get the to look anything close to a bootstrap table etc. Once done though they do allow all the needed bells and whistles. You could of course as the authors above suggest grow your own, that's always an option, but it's not why people buy controls. They are trying to leverage their time so that they can implement faster of course.
Having said all this, Telerik is the current best of breed, in my opinion by far. Easier to implement, grids are fast, have proper desirable functionality and look better.
If you use 20 Controls containing Textboxes with formlayouts, probably the Server takes a hard time to render that page containing alot of hierarchy of long tags in it. DevExpress is bad on having multiple Controls. Redering one ASPxTextbox Control could take KB compared to hundreds of byte on ASP.net Textbox control.
It very common for an entry page to have more than 20 controls. I did use devexpress for years, the speed and performance are acceptable. We use to build ERP solution.
发布评论
评论（7）
我意识到这个问题已经很老了，原作者可能早就做出了决定。然而，当我的公司亲自指示我使用 DevExpress 并且我试图找出所有可能的性能时，Google 搜索总是会指向这个线程，并且互联网上有许多类似的线程。总会有一个问题、一些轶事回应，通常还有来自 DevExpress 工作人员的 PR 回应。我很少从有经验的人那里找到诚实的答案。
过去，我使用过 Telerik、Infragistic 和 DevExpress。从性能和维护的角度来看，DevExpress 是最差的。他们的所有控件都有奇怪的属性和访问器，与熟悉 ASP.NET 甚至 HTML 的人所期望的不符。由于控件的属性和访问器非常复杂，您会发现您编写的代码行数大约是普通 .NET 应用程序所需代码行数的两倍。
DevExpress 控件被渲染为非常臃肿的嵌套表格。有些控件公开了更好的轻量级渲染模式，但它们的样式和功能与其他 DevExpress 控件不匹配，而且我发现它们在跨浏览器测试中存在很大的错误。
自定义样式需要很多很多自定义 CSS 选择器，由于控件属性的嵌套和隐藏性质，这些选择器迫使您将 DevExpress 类名编码到 CSS 中。这是非常糟糕的做法，因为 DevExpress 可以而且应该能够在他们认为合适的时候更改其内部 CSS 类名称。
这些控件还向提供资源的 DXR.axd 处理程序发出大量的 GET 请求。
毫无疑问，他们的控件在演示环境中运行良好，屏幕上仅显示 1 个控件，但在现实世界中，这些控件很糟糕，应该避免。实现您自己的控件或仅下载 Bootstrap 并使用本机 ASP.NET 控件。我用我创建的控件替换了 DevExpress，这些控件对从 .NET 呈现的本机 HTML 类型进行样式设置，下图说明了两者之间资源使用情况的一些差异。这次交换的页面布局、业务层、数据层或数据库代码没有任何变化，只是替换了我之前优化过的 DevExpress 控件，并试图用我自己的控件来榨取每一点性能。
DevExpress 与自定义控件的比较图表
I realize that this question is quite old and the original author has probably long since made a decision. However, when I was personally directed by my company to use DevExpress and I was trying to eek out all of the performance that I could, a Google search would always point to this thread and many like it across the internet. There's always a question, a few anecdotal responses, and usually a PR response from somebody that works for DevExpress. I rarely find honest answers from experienced people.
In the past, I've used Telerik, Infragistic, and DevExpress. From a performance and maintenance perspective, DevExpress is the worst. All of their controls have odd properties and accessors that do not align with what somebody that is familiar with ASP.NET or even HTML would expect. Since the properties and accessors of the controls are so convoluted, you will find that you've written about twice as many lines of code that are necessary in a normal .NET application.
DevExpress controls are rendered out as hugely bloated, nested tables. Some controls expose a lightweight rendering mode that is better, but their styling and functionality do not match with the other DevExpress controls, and I found them to be quite buggy in cross-browser testing.
Custom styling requires many, many custom CSS selectors that force you to code DevExpress class names into your CSS, due to the nested and hidden nature of the control properties. This is very bad practice, since DevExpress can and should be able to change their internal CSS class names whenever they see fit.
These controls also make an absurd number of GET requests to their DXR.axd handler that serves up resources.
There's no doubt that their controls work fine in a Demo environment with only 1 control displayed on the screen, but in the real world, these controls are terrible and should be avoided. Implement your own controls or just download Bootstrap and use native ASP.NET controls. I replaced DevExpress with controls that I created that style the native HTML type that gets rendered from .NET and the following chart illustrates some of the differences in resource usage between the two. There were no changes to the page layout, business layer, data layer, or database code for this swap, just a replacement of DevExpress controls that I'd previously optimized and tried to squeeze every bit of performance out of with my own controls.
Chart Comparing DevExpress to Custom Controls
这很糟糕，但在分配责任时我不会直接指出 DevExpress 控件 - 我会针对我的代码运行探查器来找出问题的真正所在。
That's bad, but I wouldn't point straight at the DevExpress controls when assigning blame - I'd be running a profiler against my code to work out where the issue really is.
Soham，
作为一般规则，在进行网络设计时，请尽量保持页面简洁，以便它们可以运行得更快。例如，您绝对需要在一页上有 20 个控件吗？
如果它们不需要任何特殊功能，那么您可以使用
另外，请查看我关于 用于提高性能的 DevExpress web.config 设置。
顺便说一句，我在 DevExpress 工作。 :)
Soham,
As a general rule, when designing for the web, try to keep your pages light so they can run faster. For example, do you absolutely need 20 controls on one page?
And if they do not need any special functionality then you can use the native rendering.
Also, check out my article on the DevExpress web.config settings to improve performance.
Btw, I work for DevExpress. :)
我没有 DevExpress 经验，但您可能还想查看 Improving Asp.net性能。它也可能有帮助。
I have no DevExpress experience, but you may also want to check out Improving Asp.net performance. It might help out as well.
2016 年 - 在过去的 5 年里，我依次使用了 Infragistics、Dev Express、Telerik。
基础设施学我什至不会开始，因为它本身就是一个主题。
我对 Dev Express 最大的不满是他们的控件确实给整体结果增加了一些“膨胀”。然而，某些控件确实具有值得夸大的功能集。当然，他们的 Grid 和 Pivot grid 是复杂的工具，允许用户做很多事情，而且我已经成功实现了 Devexpress 包，它们运行速度很快，效果非常好。我在使用 Dev Express 时遇到两个问题：
说了这么多，在我看来，Telerik 是目前最好的。网格更容易实现，速度快，具有适当的理想功能并且看起来更好。
2016 - Over the last 5 years I have used Infragistics, Dev Express, Telerik in that order.
Infragistics I won't even get started on because it is a subject unto itself.
My biggest pet peeve with Dev Express is their controls do add some "bloat" to the overall result. However, some controls do have feature sets that are worthy of the bloat. Certainly their Grid and Pivot grid are complex tools that allow the user to do many things, and i have successfully implemented Devexpress packages that worked both quickly with very good results. I have two problems with Dev Express:
Having said all this, Telerik is the current best of breed, in my opinion by far. Easier to implement, grids are fast, have proper desirable functionality and look better.
如果您使用 20 个包含带有表单布局的文本框的控件，服务器可能会花费很长时间来呈现包含大量长标签层次结构的页面。 DevExpress 不擅长拥有多个控件。与 ASP.net Textbox 控件上的数百字节相比，重新渲染一个 ASPxTextbox 控件可能需要 KB 的时间。
If you use 20 Controls containing Textboxes with formlayouts, probably the Server takes a hard time to render that page containing alot of hierarchy of long tags in it. DevExpress is bad on having multiple Controls. Redering one ASPxTextbox Control could take KB compared to hundreds of byte on ASP.net Textbox control.
一个入口页面有超过 20 个控件是很常见的。我确实使用 devexpress 多年，速度和性能都可以接受。我们用来构建 ERP 解决方案。
It very common for an entry page to have more than 20 controls. I did use devexpress for years, the speed and performance are acceptable. We use to build ERP solution.