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.

Free DevExpress Products - Get Your Copy Today