This Blog


Favorite Posts


December 2007 - Posts

  • Scheduling more speed

    In the latest version of ASPxScheduler (2007.3.5, the last one -- I think -- this year), we've made some important changes.

    Let's initially talk about the main "non-performance-related" changes, just to get them out of the way. Not that they're unimportant, you understand, but that I'd like to get to the meat of the matter...

    First of all, we've implemented medium trust support for the ASPxScheduler. This is a very important feature for all our users who have to host their sites using external hosting providers. This is a biggie and no mistake.

    The second main change is that we've fixed the problem where default ASPxScheduler forms were prohibited from showing, when the site was published using the "Publish Site" Visual Studio command (aka, a precompiled site). During the fixing of this problem, we were forced to find a way to get the default form template that is located at the end-user's site. We've decided to copy these templates to the site automatically the first time the user drops an ASPxScheduler onto the page (or opens a page with ASPxScheduler on it). Now the user has the form templates on his site. He should not modify these template files but instead may create copies of them and then modify these copies. To use the modified form templates the user should specify the form URLs via the ASPxScheduler.OptionsForms properties.

    This fix is kind of cool, since it now allows users to not only publish their sites correctly (duh!), but also to easily get and modify form templates easily. We'll continue to introduce template support for other parts of ASPxScheduler with subsequent releases in 2008.

    OK, that's all very well, but this post is more about performance.

    The ASPxScheduler came after our rewrite of the XtraScheduler. This latter rewrite enabled us to put into place a better-designed and faster data layer for the scheduler engine, and this data layer and scheduler engine are used in both the WinForms control and the ASP.NET control. Of course, the actual presentation of the data is very different in both environments and introduces different goals and issues that need to be overcome.

    When we released the ASPxScheduler and it started to be used by a larger base than just ourselves and our beta testers, various changes and optimizations brought themselves to the fore. I've mentioned a couple above, but another one was improving the performance of the control. Of course, to improve performance, you need to analyze it first, and for that you need working code to profile and sometimes you need a wider breadth of usage scenarios as well. Some of these scenarios we knew about, others came from our customers in using the ASPxScheduler and giving us feedback.

    There are several facets to this, just as with the ASPxGridView. There's improving the performance of the data path, as I mentioned before. The ASPxScheduler also has a bunch of Javascript to enhance the user experience (UX) in the browser (things like drag-and-drop of appointments, dragging borders of appointments to increase the time for the appointment, and so on). There's general class model type improvements as well; those that appear in our shared ASP.NET framework (essentially what Mehul talked about in his post).

    Our feedback on the scheduler's client-side UX was extremely positive. Customers liked the capabilities we'd surfaced in the browser, and there weren't many (if any) discussions about the performance there. There were a few issues about flickering during dragging operations, so we kept that at the back of our minds.

    The data path between the server and the client though, especially during a callback, seemed to need some optimization love. Analysis showed that we were transferring too much data back and forth, data that hadn't changed. So, we took another look at that path, and in 2007.3.5 we've implemented code that avoids transferring unchanged parts of the control during each callback. This deceptively simple change gives us the opportunity to quite dramatically decrease the request packet size between client and server, and, as a bonus, increase the rendering speed at the client for many common scenarios.

    And, providently, this new approach to callbacks even enabled us to get rid of the flickering during appointment dragging and resizing. Score! Pretty much three performance improvements for the price of one.

    These successes have fired up the teams to take even deeper forays into performance optimization for future releases of our ASP.NET controls; you should expect even more performance improvements in 2008. And, because many of these changes are to our shared ASP.NET framework, improvements appear across the board, often without any extra work on our (or your) part. I have to say that these successes validate our approach to layering the ASP.NET controls into shared and specific code.

  • With speed comes responsibility

    Mehul, in this post, described some of the results of the efforts we've been putting into optimizing our ASPxGridView and other miscellaneous ASP.NET controls in order to keep our pole position for having the speediest ASP.NET controls out there.

    Although "Performance is Everything" is a fun slogan, and overall speed improvements like these are very important, in reality raw performance isn't really the whole enchilada. With such speed comes great responsibility. Not yours, you understand, but ours.

    There's a truism in computer programming (and being that we're talking about computers, it's not universally true, but never mind) that many discover for themselves or have shown to them: to get greater speed you have to use more memory. Think of, for example, storing a table of pre-computed results for some calculation you do. If the result of the calculation is there in the table, use it, otherwise calculate the value from scratch and store it in the table. (The example I'm thinking of here, as it my algorithmic wont, is calculating a CRC value.)

    So, did we, in our quest for more speed, just allocate a whole chunk of memory on the server and on the client and pre-compute some values? Are we in your web server storing huge data structures in your session variable? Are we in your client futzing with your DOM? Are we in your browser's Javascript interpreter chewing it up and spitting it out? Are you or your server going to start sweating as soon as more than 10 people use your web application and page thrashing occurs?

    This is where the responsibility factor comes in. No, we didn't go for the "more memory == more speed" easy answer. Instead, we thought hard about the path that data has to take from data store to the user's browser, we took a good hard look at the design of our class model, we dissected how that class model renders HTML and how the browsers show the result. We also stepped back and looked at how to better integrate AJAX to help make the control seem more performant by doing extra work in the background. The overall result was as Mehul described it: a 2.5 times speed increase on average.

    The data path is an easy one to consider, since most issues seem to flow from it. The less data you have to chuck around to get things done, the faster things will be, especially in a web application where there are several different segments to the path (database to web server via the LAN, web server to browser program via the Internet, browser to the screen via the DOM). I'm not just talking about data from the database either: the amount and complexity of HTML and Javascript also stresses a data path (the data path from the web server to your browser and thence through the DOM parser).

    Mehul, yesterday, talked about optimizing the grid and miscellaneous controls. Tomorrow, I'll talk about another optimization we made to help make the ASPxScheduler more performant.

  • I tried, I really tried...

    ...to get Mark and the IDE team to make things simpler. It seems we have had some concerns from certain unnamed customers about being immediately productive with CodeRush and Refactor! Pro in Visual Studio 2008. I understand. It's new and all that. There's C# 3.0 with those weird looking lambda expressions. There's Visual Basic 9 with the ability to type syntax-checked XML in the code. And don't even mention LINQ. If our parser isn't up to snuff, all sorts of problems might occur. If the worst came to the worst, customers might even have to turn off some features and dumb down the product.

    So Mark sat down and over the course of a couple of, er, well, minutes came up with a list of tips to make you immediately productive with CodeRush and Refactor! Pro in the RTM version of Visual Studio 2008. Personally I think there are too many tips but he assures me that this list is the smallest he could devise. So, sorry about that, but if you do find you can remove a tip from his list we would be extremely interested to see how.

  • When is a layer cake healthy?

    Every couple of weeks or so, we receive an email or phone call asking a particular question. The question is common enough that I think I should reply to it here, in a public forum, so that I can link to or point to it in future.

    The question usually goes like this. (All numbers are made up for this discussion, but they're in the ball-park for those times I've replied. The products are not just limited to the .NET products, by the way, this Q&A applies to our VCL products as well.)

    "We have three developers doing UI work. They're the only ones using your UI controls inside the IDE. We also have ten other developers doing other work on the application, and they need to have your controls installed in order to compile it. Do we need an extra ten licenses to your product?"

    As posed, the short and indeed only answer to this question is yes. Those other developers do indeed need their own license to our product. If they can't compile the application without having our product installed, they'll need a license otherwise they are in violation of our EULA (End-User License Agreement).

    Now, of course, most customers now ask something along these lines:

    "That's ridiculous [or some other, er, similar adjectival phrase]. I don't want to buy another 10 licenses just so they can compile! Is there any way around this limitation?"

    Depending on the adjectival phrase used, I'll generally launch into my stock answer.

    Of course there's a way round this, which in and of itself is not free: divide up the application into layers. As an absolute minimum there should be two layers, although generally people choose three. The user interface (or presentation layer, in the standard architectural parlance) is a totally separate layer (set of assemblies, if you will) from the rest of the application. The other layer is a data access layer, or, if you really want to follow the standard there will be two extra layers: the business layer (containing the business rules and logic) and the data layer (containing the code needed to access and update the persistent data, be it in a file or database.

    Dividing up your application like this gives you several major benefits:

    • You only have to buy licenses to our products for those developers working on the presentation layer.
    • The layers, being separate from each other, only linked up when the application runs, are more easily testable. No longer do you have to test your business logic through the user interface; perhaps the most inefficient way of testing business logic ever devised. It means you don't have to worry about finding a testing application that drives your application through the user interface -- always an expensive proposition. Testing business logic through an interface to that logic is much easier, more thorough, doesn't break when the user interface changes, and can be done unattended.
    • You have separate, parallel development projects that can proceed at their own pace. The user interface can be developed independently of the business layer and can use a mocked up implementation to provide data. Since most applications, rightly or wrongly, are judged on their user experience, you can spend more time and effort in prototyping the UI independently of the business logic.

    There are of course some caveats:

    • The IDE doesn't help you develop these layers in any meaningful way. In fact, the very reason people like IDEs in the first place are for their RAD (Rapid Application Development) abilities and those abilities are most easily expressed by creating an application with everything dumped in one EXE file. It's just so easy to double-click a button and write the business logic there and then in the button click event handler.
    • Most developers are used to being able to have everything in one solution and being able to compile and run the whole solution. Layering your application means that ability is lost.
    • Layering your application means some more "architectural" work up front. You have to decide on how to do the layering, which pattern (MVC, MVP, etc) or presentation framework to use (for example, CAB), and to enforce its use. There is always the issue of the presentation/business layer interface and who controls it and who is able to make changes to it (which, if you think about it, has the opportunity of really breaking the application big-time).
    • You have to consider the functional testing aspects of the application more, that is, running the application as a whole rather than each layer individually.

    Of course, there are costs and liabilities associated with whatever course you take. You may decide that the convenience of allowing all developers to recompile all the application all the time far outweighs the cash outlay of extra licenses. Or you may decide the benefits of better testability are a good justification for taking the time and resource to layer an existing application, and get the reduced licensing costs for free, as it were. I'm afraid I can't help you there. But having done this layering exercise in an ASP.NET application (possibly the easiest type of application to do this to), I can vouch for the benefits of the architecture. I also know of several customers who have gone this particular route (and I'm trying to get their thoughts as a case study that we can publish).

    (As always with a discussion of what our EULA means or doesn't mean, you should consult proper legal advice if you are in any doubt. I am most assuredly not a lawyer.)

  • XtraCharts breaking change with ASP.NET

    We've had to make a breaking change to XtraCharts in ASP.NET in a minor release of DXperience due to an issue with the form designer in Visual Studio 2008 (I originally pointed this out here). Here's the long and the short of it, albeit in reverse order.

    The short: in the next minor version of DXperience, the WebChartControl has been moved to the DevExpress.XtraCharts.Web namespace.

    The long: when we started testing our products in the released version of Visual Studio 2008 we found a problem with our ASP.NET WebChartControl. When you add a custom web control from the toolbox onto the form, under certain conditions the new IDE will create an incorrect tag prefix. This causes several cascading issues, all bad.

    After lots of back and forth discussing various options, the development team came to the conclusion that there's nothing for it but to introduce a breaking change. (One proposal involved doing nothing, waiting for Microsoft to issue a fix to Visual Studio that repairs the issue. That, as I'm sure you can appreciate, is just as bad if not worse as introducing a breaking change.)

    So, we've moved all our ASP.NET-specific classes to a separate namespace; all classes that are in the DevExpress.XtraCharts.Web assembly have been moved from the DevExpress.XtraCharts namespace to the DevExpress.XtraCharts.Web namespace. Unfortunately, this is a global change and will affect all developers, whether they're using Visual Studio 2008 or not.

    The Project Converter tool that we ship can apply the required change to all *.aspx, *.ascx, *.master and *.skin files. Please note though that it doesn't fix *.cs and *.vb files, which means that you will need to manually add the DevExpress.XtraCharts.Web namespace to those source files where it's needed.

    Note that WinForms programs are not affected.


Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383


DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, Delphi, HTML5 or iOS & Android development. Whether using WPF, ASP.NET, WinForms, HTML5 or Windows 10, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2018 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners