Kommentare zu: What’s faster: method call or public access? http://narcanti.keyboardsamurais.de/whats-faster-method-call-or-public-access.html deep geeks click here Fri, 18 Jun 2010 13:54:26 +0000 hourly 1 Von: Secco http://narcanti.keyboardsamurais.de/whats-faster-method-call-or-public-access.html/comment-page-1#comment-30 Secco Tue, 18 Oct 2005 08:21:59 +0000 http://narcanti.keyboardsamurais.de/?p=48#comment-30 Well, you're all right. I had read about the optimization called inlining and am aware, that the microbenchmark is not that representative in general. My aim was to decide which one of those approaches to use in a more complex architecture. Imagine I wanted to implement a directed bigraph. There are several approaches doing so, like using adjacence matrices or adjacence lists. both of this approaches need access to several values stored in a class: the matrix needs a 2 dimensional array while the adjacence lists need linked or hashed lists. So I had to decide weather it's worth making all the arrays and lists public or encapsulate them through method calls since there would be thousands of thousands of calls to them. The experiment was just designed therefor and is so quite representative. If using getters, I just would return a value from an array or list. This experiments showed me, that, eg through the inline capability, the method encapsulation is more prefferable, since there is realy low speedloss but a very high gain of objectorientation, readability and reusability. Well, you’re all right. I had read about the optimization called inlining and am aware, that the microbenchmark is not that representative in general. My aim was to decide which one of those approaches to use in a more complex architecture. Imagine I wanted to implement a directed bigraph. There are several approaches doing so, like using adjacence matrices or adjacence lists. both of this approaches need access to several values stored in a class: the matrix needs a 2 dimensional array while the adjacence lists need linked or hashed lists. So I had to decide weather it’s worth making all the arrays and lists public or encapsulate them through method calls since there would be thousands of thousands of calls to them. The experiment was just designed therefor and is so quite representative. If using getters, I just would return a value from an array or list. This experiments showed me, that, eg through the inline capability, the method encapsulation is more prefferable, since there is realy low speedloss but a very high gain of objectorientation, readability and reusability.

]]> Von: Toni http://narcanti.keyboardsamurais.de/whats-faster-method-call-or-public-access.html/comment-page-1#comment-27 Toni Thu, 13 Oct 2005 18:25:35 +0000 http://narcanti.keyboardsamurais.de/?p=48#comment-27 I am sorry to say so, but you are making a very common mistake here. You do a microbenchmark and assume that it has some validity performancewise, when really in the background the jvm is doing something else. What I am talking about is the JIT capabilities of the JVM and not only JIT but also the compilier inlining feature. Let me show you something I found in an Article from 1998. <blockquote> Fortunately, today's JIT-enabled Java environments perform method calls much faster than earlier non-JIT-enabled environments. There is less of a need to make speed-versus-encapsulation tradeoffs in these environments. With the best JIT, static methods returning nothing and taking no arguments execute in 2 clock cycles. Non-static method calls returning integer quantities execute in 7 clock cycles. Non-static method calls returning floating-point numbers execute in 8 clock cycles. Taken from a really old article on <a href="http://www.javaworld.com/javaworld/jw-09-1998/jw-09-speed.html" rel="nofollow">Javaworld</a> </blockquote> This, and the compiler inlining makes this benchmark invalid. You may have measured something that in real life would perform otherwise. 2005's JDK 1.5 is so complex and feature ridden, that microbenchmarking something like that is just not fair. Rest assured, you will not loose performance because of method calls - well, unless you really mess up the jvm ;-) I am sorry to say so, but you are making a very common mistake here. You do a microbenchmark and assume that it has some validity performancewise, when really in the background the jvm is doing something else. What I am talking about is the JIT capabilities of the JVM and not only JIT but also the compilier inlining feature. Let me show you something I found in an Article from 1998.

Fortunately, today’s JIT-enabled Java environments perform method calls much faster than earlier non-JIT-enabled environments. There is less of a need to make speed-versus-encapsulation tradeoffs in these environments. With the best JIT, static methods returning nothing and taking no arguments execute in 2 clock cycles. Non-static method calls returning integer quantities execute in 7 clock cycles. Non-static method calls returning floating-point numbers execute in 8 clock cycles.

Taken from a really old article on Javaworld

This, and the compiler inlining makes this benchmark invalid. You may have measured something that in real life would perform otherwise. 2005′s JDK 1.5 is so complex and feature ridden, that microbenchmarking something like that is just not fair. Rest assured, you will not loose performance because of method calls – well, unless you really mess up the jvm ;-)

]]>