In the latest version of
(2007.3.5, the last one -- I think -- this year), we've made some
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
OK, that's all very well, but this post is more about performance.
The ASPxScheduler came after our rewrite of the
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
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
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
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