+972 52-548-6969
The Performance Penalty of using ASP.Net
Bret is talking about tracking an issue with Watir that appeared after the application was migrated from ASP.Net to Ruby on Rails (IE issue, apparently).
I think the reason we haven’t seen this problem before is because our .Net apps have been a lot slower that Rails. Slow enough to keep this IE bug from showing up.
That is certainly something that I have seen before. The main problem is not the runtime performance, it is the initial performance. If I make a change to a page, I have to wait ~30 seconds for it to load. Contrast that with making a change to a MonoRail view, where a change in the view appears instantly. The problem is that changing the controller requires re-compilation, which has the same performance penalties.
This is something that kept me annoyed, but it is getting more so lately, because I can feel the difference between changing the view (brail, instant) and the controller (C#, ~30 seconds), where before anything that changed caused the same long delay.
As far as I can tell, this has to do with AppDomain load / unload, but I never really bothered to take a look. William was talking about this same problem a while ago. This may not affect the runtime production performance, but it plays hell with the developer's performance.
Comments
Have the same problem, and it's driving me insane. As you say runtime perf. is okay, but when I run my project locally it takes ages to do anything. In my opinion it might be the single biggest drawback to ASP.Net development.
I don't know why anybody uses Rails considering it doesn't run on the two most popular web servers (Apache and IIS).
Have you ever considered running aspnet_compiler.exe on your ASP.NET applications? We have been making this a practice for our QA and Production environment and we see marked startup performance improvement.
Absolutely, compilation in ASP.NET is a huge performance penalty during development time. If anybody knows of a way to speed up compile time of large ASP.NET projects, we'd love to hear it
Rails doesn't run "on" Apache. It runs behind Apache. More precisely, Mongrel runs behind Apache, and Rails runs on it - like a web garden in IIS, except with sufficient decoupling in the infrastructure to allow plugging in components from different sources... If you're into that sort of thing.
I run Rails not for the choice of ancillary environment choices it give me, but for the efficacy of value realization versus other frameworks I know.
<< our .Net apps have been a lot slower that Rails.
That is certainly something that I have seen before. The main problem is not the runtime performance... >>
Runtime performance of Rails apps is in fact a lot slower than .NET apps.
I love Rails, but when I ran some tests on Windows with the same pages, they took 2 or 3 times longer to load than the ones on .NET and Monorail.
I agree with Scott though, to save on development time, Rails is hard to beat, but if you have a single Windows server where you run quite a few Rails apps, how many Mongrel processes do you need?
Wouldn't this be hard on the server?
Jeff,
I am talking about on the dev environment, I couldn't care less for the production startup time.
Also, are you using Web Site or Web Application Project?
"Hell for developer's performance" totally agree, its one of the biggest PITA which entitle the honorable word SUCKS.
I still remember the worst thing I have seen is the time needed for asp.net web project (not the web application project which only compiles CS). MS claims it checks all the XML in ASP.NET which is the reason why it is hell slow. I don't give a shit on what they are checking, I am talking about realistic development environment. With the time needed to recompile, it adds up as doing at least one simple routine test using interactive ruby. Try to calculate how many times you hit the stop and start again and then multiply as a month, then you know how many more testing you could do on ruby to grow your experience so you are less likely to commit stupid mistake. Compiler suppose to help us do checking for program, but losing that much time a day basically ruin up the advantage of having a compiler.
I am indeed very interested to the recent effort off IronRuby. If this thing really takes flight and running Ruby on Rails on it, I think I would probably find a chance to switch to Ruby- given the advantage I could call almost every .net libraries (e.g. Windsor)
J,
Runtime performance is important, but add all those 30 seconds delays and you get a lot of time of me twiddling my thumbs. While this is certainly something that is of some importance, it is not really a productive way for me to spend my time.
That time usually adds to another server or two or more.
Scott,
"Rails doesn't run "on" Apache. It runs behind Apache. More precisely, Mongrel runs behind Apache, and Rails runs on it "
AFAIK its not most production RoR project would do. Thats too slow and unnecessary. If people want power of Ruby all the way to web servver, Mongrel only is the best. If they want to squeeze every bit of performance, I think they do Apache/lighttpd + FastCGI to call Ruby/Rails directly.
Its called the Compilation Tax... Yes, AppDomain does get unloaded and reloaded because aspnet detected some changes it wants to JIT and load. The details are messy, but it amounts to a PIA for devs. I used to read Brad Abrams for CLR info like this.. not sure if he is still in that area.
http://blogs.msdn.com/brada/
Frankly, I don't give a damn about the why.
It is a major pain for developers. And there really isn't a good way to override this behavior. I don't care if it takes more memory when I am developing, I just want it to work fast.
ASP.Net launch is super slow. 30 seconds is nothing compared to the couple minutes that our web team often ends up waiting for with some of the larger projects.
I'm making it a priority to get the wait time down in various ways but there are fundamental performance limits of the C# compile-edit-debug cycle. One of the few things I really miss from Java is the incredibly fast background incremental compilation that the Eclipse JDT does.
Try out the IronPython integraion in ASP.NET futures download from MSDN. Compilation tax goes bye-bye! I showed this to my co-worker and his jaw dropped open. You get intellisense and fast edit-test-debug.
The one thing I don't like about IronPython is that there is no concept of Attributes (yet).
Oh, also you have about half the code b/c there is no need for a class declaration to handle the code behind. Just a bunch of Python functions.
Comment preview