Performance Issues

Performance is always a question in people's minds, and often is raised during beta testing when there's lots of debugging code hanging around in the product. Even in the early betas, it was clear that ASP.NET was faster than ASP, with figures showing that it was 2 to 3 times as fast.

One of the reasons for this performance improvement is the full compilation of code. Many people confuse Intermediate Language ( IL ) and the CLR with byte-code and interpreters (notably Java), and assume that performance will drop. Their belief in this deepens when they first access an aspx page, because that first hit can sometimes be slow. It's because pages are compiled on their first hit, and then served from the cache thereafter (unless explicit caching has been disabled).

Note

Appendix B has a list of tips and tricks to help with performance.

Languages

Although all languages compile to IL and then to native code, there may be some slight performance differences, due to the nature of the compiler and the language. In some languages, the produced IL may not be as efficient as with others (some people have said that the C# compiler is better than the VB compiler), but the effects should be imperceptible. It's only under the highest possible stress situation that you may find differences, and to be honest, I wouldn't even consider it a problem.

Late-Bound Code

One of the greatest advantages of the CLR is fully typed languages. However, you can still use JScript.NET without data types, allowing legacy code to continue working. The disadvantage is that types then have to be inferred, and this will have a performance impact.

In Visual Basic, if strict semantics are not being used (either by the Option Strict Off page directive or by the /optionstrict- compiler switch), then late-bound calls on object types are handled at runtime rather than compile time.