Una posible explicacion: "Once I heard a .NET architect confess his need to sacrifice encapsulation for performance. He said that .NET has a data structure with a few fields that were accessed so often that wrapping them with getters and setters caused a significant performance impact on the speed of the application.Well, maybe .NET needs to do that. Bear in mind that Java doesn’t need such tricks at all. In the autumn of 1998, I visited a Sun Microsystems conference in Berlin, where JavaSoft’s boss said something like, “Yes, interpreted code can be faster than code that is compiled.” At that time I wasn’t working for Sun yet, and I also knew how terribly slow Java was. So I laughed, along with the majority of the audience. However, since then I’ve spent time thinking about those words. In the meantime, the JVM saw significant improvements when Sun released its HotSpot virtual machine. HotSpot first interprets bytecode provided by class files and then monitors the application to find critical pieces of its code and its setup. After some time, it compiles the parts of the application that are executed most frequently. But unlike with static compilation, which precedes linkage, the HotSpot compiler already knows the result of a linkage because the classes are already loaded. So, the HotSpot compiler can optimize the compiled code for the current setup and not for the general scenario as a regular compiler has to do. As a result, the HotSpot compiler can, for example, inline virtual methods. Anyone who has tried to simulate virtual methods in C knows that this requires at least one access to memory and one indirect jump. The HotSpot compiler can do much better. As it knows the linkage information, it can find out that some virtual method isn’t overridden at all, or that, for example, two other classes override it twice. Then it can replace the regular call directly with the method’s body. Alternatively, if there is more than one, but less than many, it can replace the memory indirection with a simple switch. This is a lot faster than the plain virtual methods table that static compilation or a programmer trying to simulate this in C has to use. Though it’s true that interpreted code is unlikely to be faster than code that is compiled, if we correct the statement I had heard in Berlin a bit, we can justifiably say, “Dynamically compiled code can be faster than code that is statically compiled,” which was likely the point of the talk to begin with.We can, with the help of the HotSpot compiler, see that this statement has turned out to be true. Remember that the HotSpot virtual machine is capable of inlining method calls, including virtual method calls if the method is being called too often. As a result, frequently used getters and setters have no performance impact, as HotSpot eliminates them. Thus, there is no need to sacrifice API encapsulation for performance in Java. "
2011/1/28 Gorka Prieto <[email protected]> > No sabía si poner el off-topic en el subject, así que lo pongo aquí ;P > > Buscando pruebas de tiempos de ejecución de diferentes lenguajes y runtimes > he > dado con estas gráficas que seguro que a alguien más de la lista le > interesan. > > Me llama la atención la "poca" diferencia de tiempos entre C++ y Java/.NET > y > también me ha sorprendido el mejor rendimiento de las plataformas libres :) > > Yo hace unos años hice mis pruebas con algoritmos de procesamiento de señal > y > los resultados eran mucho más favorecedores para C/C++ y especialmente > malos > para Java frente a .NET, pero estas gráficas rompen un poco mis esquemas. > Alguien en la lista que pueda aportar un poco más de luz sobre el tema? > > Saludos! > ________________________________________________________________________ > Dr. Gorka Prieto Agujeta > Departamento de Electrónica y Telecomunicaciones (DET) > Universidad del País Vasco (UPV/EHU) > Escuela de Ingeniería de Bilbao > Alda. Urquijo s/n mailto: [email protected] > 48013 - Bilbao Phone: +34 94 601 3994 > Bizkaia Fax: +34 94 601 4259 > ________________________________________________________________________ > > _______________________________________________ > ITSAS mailing list > [email protected] > http://list.ehu.es/mailman/listinfo/itsas > >
_______________________________________________ ITSAS mailing list [email protected] http://list.ehu.es/mailman/listinfo/itsas
