El Bruno

Tratando de optimizar un poco la perfomance de un par de aplicaciones Asp.Net, me reencontré con este artículo de Rob Howard de la MSDN magazine de Enero del 2005. Al revisar un poco del “sentido común” que propone al momento de diseñar, codificar e implementar aplicaciones Asp.Net, me encontré con este pequeño sidebar que acompaña al articulo.

Como los puntos que trata son interesantes y hace unos días estuve en una agitada conversacion al respecto, creo que es buen momento para refrescar estos temas:

·         C# es más rápido que Visual Basic .Net.

One of the most common myths  is that C# code is faster than Visual Basic code. There is a grain of truth in this, as it is possible to take several performance-hindering actions in Visual Basic that are not possible to accomplish in C#, such as not explicitly declaring types. But if good programming practices are followed, there is no reason why Visual Basic and C# code cannot execute with nearly identical performance. To put it more succinctly, similar code produces similar results.

·         Codebehind es más rápido que code inline.

Another myth is that codebehind is faster than inline, which is absolutely false. It doesn’t matter where your code for your ASP.NET application lives, whether in a codebehind file or inline with the ASP.NET page. Sometimes I prefer to use inline code as changes don’t incur the same update costs as codebehind. For example, with codebehind you have to update the entire codebehind DLL, which can be a scary proposition.

·         La ejecución de los omponentes es más rápida que la de una página.

Myth number three is that components are faster than pages. This was true in Classic ASP when compiled COM servers were much faster than VBScript. With ASP.NET, however, both pages and components are classes. Whether your code is inline in a page, within a codebehind, or in a separate component makes little performance difference. Organizationally, it is better to group functionality logically this way, but again it makes no difference with regard to performance.

·         Todas las comunicaciones entre aplicaciones deben ser implementadas a través de WebServices.

The final myth I want to dispel is that every functionality that you want to occur between two apps should be implemented as a Web service. Web services should be used to connect disparate systems or to provide remote access to system functionality or behaviors. They should not be used internally to connect two similar systems. While easy to use, there are much better alternatives. The worst thing you can do is use Web services for communicating between ASP and ASP.NET applications running on the same server, which I’ve witnessed all too frequently.

Interesantes conceptos.

Saludos.

PD: la fuente es MSDN, no la he escrito yo 😀