ASP与ASP.NET的执行效率，哪个更快？

ASP.net是把基于通用语言的程序在服务器上运行。不像以前的ASP即时解释程序，而是将程序在服务器端首次运行时进行编译，这样的执行效果，当然比一条一条的解释强很多. 

asp解释执行： 

客户端->访问a——>服务端-->从数据库调用a——>iis解释——>返回ie 

客户端->访问a——>服务端-->从数据库调用a——>iis解释——>返回ie 

(每次循环) 

asp.net通用语言的程序在服务器上运行 

客户端->访问a-->服务端-->编译执行-->返回ie-->记录(再访问无需编译直接返回给ie) 

客户端->访问a-->服务端-->返回ie 

（仅仅一次） 

不才！ 就当混分的不要骂就可以了！

编译还是解释快 这是一个问题
彪悍的人生不需要解释。

但是在选择使用编译方式还是解释方式，来实现脚本语言的时候，是个不那么容易的问题。

现代语言的“编译”和“解释”已经和10年前的概念不一样了。

因为其实很少有脚本语言是真正每执行一句解释一句，然后下次再执行还要解释一次的，现在所有的脚本语言， 包括perl，ruby，php,asp等等，都是第一遍解释的时候翻译成中间代码放在内存里， 供下一次执行调用的。

而如果按照以前对”编译“的定义 - 把程序翻译成cpu可以执行的机器语言，现在常用的语言，除了C/C++,应该都不算编译型的语言了。

所以，编译还是解释，在这里的含义其实是，把源程序翻译成怎样的中间代码。

ASP.net应该是和java一样，翻译成类似汇编的指令集，然后由CLR执行。也就是类似编译的方式。

perl，php，ruby，包括ASP, 应该都是仅仅翻译成优化或没有优化过的语法树，然后IIS通过遍历语法树来执行程序。

究竟哪个效率更高呢？

因为计算机理论告诉我编译要比解释快多了。

但是，现在解释型语言的效率看上去并不那么差， 而且如此的盛行， 反而，ASP.net的缓慢让人失望。

虽然解释和编译都是把程序翻译成了中间代码， 然后执行，但是各有优劣。

解释型的好处是，不用翻成很泛的伪汇编语言，很多地方可以直接翻译成特定功能的代码，比如ASP中，把一些函数不翻成普通的函数调用， 而是直接翻译成执行该功能的指令，就像response.write，就直接翻译成do_write，而不是翻译成一堆汇编，do_writes直接对应一个执行函数，取得参数，然后调用stream的write。这要比一堆伪汇编生成的函数调用去调用用另一堆伪汇编实现的do_write，应该要快很多。

当然，函数调用只是个例子，专门的总是泛的要快，这是肯定的。

但是解释型的脚本语言，在普通的表达式计算上， 应该是没有编译型的快， 因为这没有专用可言， 大家都翻译成一堆加减乘除运算，但是编译型语言对中间代码和ASP的优化余地要大的多。

编译方式的缺点是必须翻成很泛的中间代码，比如伪汇编， 这种生成的伪汇编的代码量会比源程序大上很多，复杂上很多，通用的代价就是自身会变复杂。而脚本语言的中间代码要简单的多。

而且ASP.net要开销大量的内存，大量的线程调度也会拖慢执行速度。这是为什么大家觉得不支持线程的语言做的网站要比ASP.net快的原因。

我主要要问的是：为什么解释执行要比编译后执行的效率高。这也是我给这么高分的原因。

你这句话不对吧

按照正常的： 编译后执行的效率高

编译后执行是 在编译的时候把源代码 编译成可执行的 二进制，执行时直接中二进制代码在机器上运行。

但是解释执行存储的只是源代码（不是二进制代码），每次执行要把它重新编译成二进制代码，中间多了一个转换过程，效率自然低了

这么说吧，解释执行就像在终端上打一条命令或语句，解释程序就立即将此语句解释成一条或几条指令并提交硬件立即执行且将执行结果反映到终端，从终端把命令打入后，就能立即得到计算结果，很方便，但是一旦遇到像循环这样的程序时，也只能重复进行翻译，效率非常低下，就像“口译”一样，说一句翻译一句，不会产生完全翻译好的文件；而编译执行则是先分析，后综合，最终得到目标程序，即程序源代码“翻译”成目标代码（机器语言）执行，这样才处理一些比较复杂的问题时，效率自然要比解释执行高很多。

asp.net的执行效率确实要高些，甚至敢与html媲美，但问题是要针对什么人写的程序，一般的菜鸟写的程序体现不出他的效率，甚至比asp还慢，尽管已经编译成dll。如果要开发，还是要根据自己的情况而论。不能听说asp.net快就只想到用asp.net。我在网络公司上班，以用asp及asp.net开发了很多网站，但asp.net的效率精髓还是没悟处多少