Well I have been testing a few of the other AJAX frameworks suchs as comfortASP and telerik's callback and they are both much more responsive than Atlas (just an observation - didnt do any hard benchmarking with fiddler), but there is a much more comprehensive review athttp://www.daniel-zeiss.de/AJAXComparison/Results.htm
hello.
i haven't used any of the others extensivelly, but i can assure you that atlas can be a very performant library. it all depends on the approach you take and the code you write. for instance, you can't expect to have the same performance when you call a page method and a web service method...
Hi,
You're right, I have also found that ATLAS is not as responsive as some of the other frameworks, but you have to take into account that it offers much more than some other frameworks. The site that you mention only compares certain aspects of the frameworks.
You also have to take into account that the test done were using HelloWorld, and for a simple application like that you really are not going to see real benefits, as there is little HTML in it and using ATLAS for it in a real world scenario would make no sense as the drawbacks outweight the benefits. However, in a real world application, where you will most likely be making many AJAX callbacks, the overheads of loading the framework are overshadowed by the performance benefits realized duing the callbacks.
Personally, I wouldn't go with anything but ATLAS as it seems Microsoft has a lot of resources behind it, compared with the other guys and no doubt it will be the dominant player.
Also I'm not sure the team will be able to hugely reduce the initial framework download size, althogh that would be nice.
Nick
hello.
i think that reducing the download size is a matter of better modularization, ie, create more files with less things
Hi,
Yes, good point, but i think it would be really nice if it is controllable by the developer when the js files are downloaded, although i don't really see how the actual ATLAS framework can be split up as such.
Nick
hello.
well, if you take a look on the atlas.js file, you'll see that it has several things defined in it (oo extensions, utility classes, behaviors, controls). i think that breaking this into several files won't be that difficult.
The Zeiss benchmark needs to be taken with a grain of salt. First, Daniel is himself the author of an Ajax framework so he can't be completely impartial and he's naturally going to show what makes his own work look good. That's OK, he doesn't hide in his page that he's the author of the framework on the first column of his tables.
Second, he focuses on total network payload size in a special case, UpdatePanel. Atlas is a lot more than that and UpdatePanel is just the easiest way to get updates from the server. Atlas.js, which is the full framework, does a lot more than UpdatePanel which explains why it's larger than most other frameworks. We're actively working on making the size of the script you need for UpdatePanel much smaller as well as on ways to be more finely granular while keeping the advantages of caching and limiting the number of requests.
Please note that the framework download is a one-time thing, after which it will be cached by the browser (although Daniel's numbers don't seem to reflect that for some reason that remains mysterious to me).
One nice thing he does, though, is use a PageStatePersister so that the ViewState doesn't enter the network payload. While it's nice that he's trying to test all frameworks in a similar situation, this is not what most users will want to do as there are many drawbacks to storing ViewState in session (scalability, ability to open two browsers windows on different states of the application, etc.). So the fair comparison in my opinion would be *with* ViewState integrated into the payload because that's the configuration most people will be in. Except that two of the framework can't do that at all.
I downloaded the source code for the test and clicking on the button resulted in a single request with a response1359 bytes long (header excluded but that makes little difference). That's very different from the58129 he's claiming and puts Atlas as the best one. That's without changing *anything* in his code and running in debug mode. I just don't understand where his numbers come from in diagrams 4 and 5, it seems like the framework was downloaded again for some reason, which shouldn't happen if the application is run in release mode (the script files are then cached and don't need to be downloaded again) and sure doesn't in my own tests.
The comparison doesn't take into account the scope of the framework. All of these frameworks work only in very constrained situations, typically when the controls inside the panel behaves according to a set of assumptions. Some have stronger assumptions than others.
Finally, this work is dated and a lot of things have been fixed in Atlas since then (for example, TreeView works now) but not in the document even though it claims to have tested the April CTP.
Please be assured that we're taking performance very seriously and that we'll make every effort to improve it.
The benchmarks are interesting but useless. Atlas != AJAX.
I second making Atlas more modularized, some pages I am using large chunks of the Atlas library and some pages I am only using the Glitz. I think most of the problems people are having is the large size of the scripts. I realize there isn't an optimal solution as loading a lot of external scripts can be a slow (at least initially). Will everyone be happy with one solution? Probably not. Ideally we would have some level of control over how the scripts are broken down and resources are loaded.
Another place where I think Atlas can see some improvement would be in terms of javascript optimization, even though I am not sure what kind of improvements we would see. Some js in Atlas (debug) is done with things like for (...; i < array.length; ..) there can be some (minimal) speed improvements with counting backwards and comparing i != 0. I think some of the team members do this already, while others don't. While improvements in IE are minimal they can be fairly big on Mozilla based browsers. Not really much more in terms of speed improvements.
No comments:
Post a Comment