5

i have recently converted a classic asp application to ASP.NET 3.5, but i feel that my Classic ASP version was a bit faster (i don't know may be buyers remorse).

So can you guys help me with this and let me know which one is faster, asp, asp.net or ASP.NET MVC.

I searched for this question on so and didn't find anything, if you find anything, please point to that question and mark my question as duplicate

Thank you guys.

Vamsi
  • 4,237
  • 7
  • 49
  • 74
  • Don't take this the wrong way, but how optimised is your .net code? using some tools, like fiddler would let you time how long it takes to do gets, posts, etc and give you some hard facts. – Simon Halsey May 19 '11 at 10:31
  • There is nothing take it wrong simon, functionality wise both the classic asp and asp.net application does the same thing, i tried to use the same or equavelnt datat types and controls in both – Vamsi May 19 '11 at 10:45
  • I think you have far more control in Classic ASP and its easier to write code that performs fast. .NET likes to abstract a lot of things I think, personally I think .NET feels bloated – Marcus May 19 '11 at 18:52

7 Answers7

10

Classic ASP will interpret the script for a page on every page request. ASP.NET will compile the code for the page once. ASP.NET will almost always perform better than classic ASP. ASP.NET MVC is simply a (better?) way to write ASP.NET applications.

Also, in my oppinion the features ASP.NET is far superior to classic ASP. You should be able to spend fewer developer resources on creating a more complex website if you choose ASP.NET.

Martin Liversage
  • 104,481
  • 22
  • 209
  • 256
  • 3
    in certain circumstances, MVC may be faster, as there isn't any viewstate. – Simon Halsey May 19 '11 at 10:30
  • ASP.NET doesn't require view state. However, if you use ASP.NET Web Forms you will have to take that into account. ASP.NET MVC is in many ways "lighter" than ASP.NET Web Forms both in terms of stuff like viewstate but also a tendency to generate simpler HTML. – Martin Liversage May 19 '11 at 10:33
  • true, hence the vagueness in my comment :o) – Simon Halsey May 19 '11 at 10:38
  • 3
    I don't like this answer. While it makes sense and I agree with it you haven't provided any data and simply said it should be faster. – John Farrell May 19 '11 at 12:41
5

As ASP uses interpreted code and ASP.NET uses compiled code, ASP.NET is waaaay faster to execute code.

However, this does not automaticaly mean that an ASP.NET application always is faster than an ASP application. A lot of the performance depends on database efficiency and how much data you send between the server and the browser.

When using ASP.NET webforms, it's easy to get a lot of overhead in the viewstate that is send back and forth between the server and browser, which is probably why you don't see much of an improvement in your application.

ASP.NET MVC doesn't have the same form of controls that uses viewstate, so you won't accumulate overhead as easily.

Guffa
  • 687,336
  • 108
  • 737
  • 1,005
4

It's always a bit of a sin to say "x is faster than y" but I think this is an instance where I can say Classic ASP is slower than ASP.net, excluding a few edge cases you might be able to find, one of the main reasons being Classic ASP is interpreted and ASP.net is compiled.

Tom Gullen
  • 61,249
  • 84
  • 283
  • 456
  • another point, the VBScript interpretor is no where near as optimised as the .Net framework when it comes to executing the page content. – Simon Halsey May 19 '11 at 10:47
3

In terms of performance, Classic ASP is definitely slower, for the simple reason that ASP.Net is compiled, and Classic ASP is intepreted.

ASP.Net MVC and ASP.Net WebForms both build on top of IHttpHandler (the basis of the Page object used in MVC/WebForms)

Using ASP.Net WebForms or ASP.Net MVC, you can use HttpHandler to serve things up faster (.ashx). Further reading

ASP.Net WebForms is often heavier (slower) on the client-side due to some bloated client-side framework (heavy JS libraries) and conventions suchs as the ViewState.

Further Reading

Community
  • 1
  • 1
Phil Ricketts
  • 8,236
  • 3
  • 28
  • 31
  • "often heavier"? only if you choose to use the MS javascript libraries. It's possible to write webforms as light as MVC. saying they're built on HttpHandlers is like saying they both use IIS. I'm not sure how you don't use HttpHandlers. and faster than what? Perhaps your point wasn't clear. – Simon Halsey May 19 '11 at 10:42
  • I agree, it is completely possible to avoid the overhead of WebForms by avoiding the webform framework libraries. However, I think it's fair to say that often websites built with WebForms and associated controls, are heavy on the client-side (crap). I've made a corrective edit above, regarding the HttpHandler. – Phil Ricketts May 19 '11 at 10:55
  • I would agree the web controls generate sub-optimal html, which gives the appearance of being heavier. Strictly speaking, although a ViewPage inherits from Page & thus implements IHttpHandler, it is MvcHttpHandler that does the work. But I'm being pedantic. – Simon Halsey May 19 '11 at 11:12
1

Some things in ASP.NET are not as simple to do without writing much code. I believe if your ASP code was faster and you're doing simple things then you're better of staying with it. I still build in classic ASP if i can get it done faster than ASP.NET.

I feel .NET is for complex sites or projects where only the best will suffice..but i may be wrong. In ASP you can do a lot of bastardization the client wants.

webb
  • 215
  • 1
  • 5
  • 12
0

Classic ASP is an interpreted scripting language. ASP.NET compiles down to machine code, so it will most likely be significantly faster (there might be some edge cases and wierdo optimizations in Classic ASP).

ASP.NET MVC is just a thin layer on top of ASP.NET Runtime.

Anton Gogolev
  • 113,561
  • 39
  • 200
  • 288
  • ASP.NET does not compile to machine code. It compiles to Intermediate Language. This is executed at runtime by the CLR which does just-in-time (JIT) compilation to machine code. MVC is not a thin layer on top of ASP.Net, it's a seperate set of classes that uses some of the same framework as webforms – Simon Halsey May 19 '11 at 10:45
  • @Simon: I know about JIT, but when code is JITted to native image, the latter is used to service requrests. And "separate set of classes" does not negate "thin layer". – Anton Gogolev May 19 '11 at 10:57
  • but the normal way web sites are run, the dynamic assemblies generated are not ngen'ed, so they aren't machine code until they're JIT'ed – Simon Halsey May 19 '11 at 11:03
  • @Simon. Agreed, but what _ultimately_ gets executed is native machine code, whereas ASP is interpreted no matter what. – Anton Gogolev May 19 '11 at 11:57
0

People automatically assume that a compiled application will ALWAYS run faster than an interpreted application. While that's generally true, (C# code will almost always run exponentially faster than VBScript), you have to look at the other dependencies that exist and the environment in which the application is run.

In reality, most of the time there's a negligible difference in a simple web application where you're requesting a web page, grabbing it's associated data from a database and then returning it to the browser. Requesting and returning data from the database probably consumes at least 60% of the processing of the page, another 30% is the web server creating the response.

Example, a poorly designed SQL query will slow down your app exponentially more than the chosen language you're using. Remember, it's all about the algorithm!

Trying to be objective here, but I've noticed only negligible difference in returning the same data to the same web page with ASP.NET MVC with C# and ASP. I think you'd see the same results with Spring MVC or PHP, or even ASP.NET MVC with Visual Basic.

That said, I would prefer to use ASP.NET MVC everytime because it gives me the option of using asynchronous controllers and asynchronous actions. I also like to design an application with meaningful objects. It's impossible to do ASP with OOP unless your writing the back end in C++ with ActiveX, which is an ugly solution for modern applications. ASP doesn't lend itself well to SOC (Separation of Concerns), so most ASP apps resemble a kitchen sink with a weeks worth of dirty dishes.

Charles Owen
  • 2,403
  • 1
  • 14
  • 25