Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > method calls faster than a loop?

Reply
Thread Tools

method calls faster than a loop?

 
 
Oliver Wong
Guest
Posts: n/a
 
      03-16-2006

"Roedy Green" <(E-Mail Removed) > wrote in
message news:(E-Mail Removed)...
> On Thu, 16 Mar 2006 09:40:48 -0000, "Chris Uppal"
> <(E-Mail Removed)-THIS.org> wrote, quoted or indirectly
> quoted someone who said :
>
>>
>>The JIT takes time to realise that something should be optimised, and then
>>takes longer still actually to do the optimisation. So /always/ run the
>>target
>>methods several times, printing out the time taken for each run.

>
> You want to find out how long it takes to notice the optimisation is
> needed, then do a run that discards the timings prior to that point. I
> call these cold and warm benchmarks.
>
> Both are interesting. Sometimes you will not run the program long
> enough for the optimisation to kick in, and the slow speed is the one
> you really want.
>
> see http://mindprod.com/jgloss/benchmark.html


Note though that a JIT optimizier might do several layers of
optimizations. That is, if it notices a method being run 500 times, it might
try some "easy" optimizations first. When it counts 2500 invocations, it
might then try a "medium" optimization, and so on.

- Oliver

 
Reply With Quote
 
 
 
 
Chris Uppal
Guest
Posts: n/a
 
      03-17-2006
tom fredriksen wrote:

> Is this what you mean? at lest now I am getting the correct proportions.
> Code at end of post.


Pretty much, yes.

A couple of minor nitpicks: the code for the two cases isn't quite as similar
as it could be -- for instance in one case you create one object for each timed
test, and access the random stream from one of its instance fields on each
iteration, whereas in the other test you (unnecessarily) follow a different
pattern where no object is created and the reference to the random stream is
held in a local variable. I doubt if that makes much difference, but why
introduce obscuring effects into the equation at all ? (Especially when the
purpose of the exercise is to /discover/ what kinds of effects small
differences make -- so you shouldn't "just assume" that instance fields are
accessed at the same speed as values on the stack.)

Also I would have skipped straight to the "Mixed" loop (as you call it). I
can't see much point in running one set of tests, then the other, and then
interleaving them. BTW, in case it's not obvious, the reason for interleaving
the tests is just to minimise any skew caused by whatever external influences
might be affecting the test.


> Elapsed time: 101798
> Elapsed time: 95341

[...]
> To me the number show loops are faster. It has 10 billion
> calls/iterations per test


If I haven't misread the code, then I think there are 1 billion iterations per
test. Suggesting that the overhead per call, in this particular case, is
around 6 nanoseconds. Which doesn't seem too implausible to me, although I
would expect to get different results (both higher and lower) with different
tests.

> Of course there are many issues to consider for how correct the
> measurements are, and it should also be tested in C++ and in C as
> comparison, but the numbers are interesting background information to
> have for the future.


Agreed, and -- like you apparently -- I think that every competent programmer
should have a gut sense of cost-breakdown of their code.

-- chris


 
Reply With Quote
 
 
 
 
tom fredriksen
Guest
Posts: n/a
 
      03-17-2006
Chris Uppal wrote:
> tom fredriksen wrote:
>
>> Is this what you mean? at lest now I am getting the correct proportions.
>> Code at end of post.

>
> Pretty much, yes.
>
> A couple of minor nitpicks: the code for the two cases isn't quite as similar
> as it could be -- for instance in one case you create one object for each timed
> test, and access the random stream from one of its instance fields on each
> iteration, whereas in the other test you (unnecessarily) follow a different
> pattern where no object is created and the reference to the random stream is
> held in a local variable. I doubt if that makes much difference, but why
> introduce obscuring effects into the equation at all ? (Especially when the
> purpose of the exercise is to /discover/ what kinds of effects small
> differences make -- so you shouldn't "just assume" that instance fields are
> accessed at the same speed as values on the stack.)
>
> Also I would have skipped straight to the "Mixed" loop (as you call it). I
> can't see much point in running one set of tests, then the other, and then
> interleaving them. BTW, in case it's not obvious, the reason for interleaving
> the tests is just to minimise any skew caused by whatever external influences
> might be affecting the test.


Thats how I understood what you where saying, but it does not affect it,
only makes the test take more time

>
>
>> Elapsed time: 101798
>> Elapsed time: 95341

> [...]
>> To me the number show loops are faster. It has 10 billion
>> calls/iterations per test

>
> If I haven't misread the code, then I think there are 1 billion iterations per
> test.


Yes, I see there is a typo, so the code decides.

/tom
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      03-17-2006
On Fri, 17 Mar 2006 10:45:43 -0000, "Chris Uppal"
<(E-Mail Removed)-THIS.org> wrote, quoted or indirectly
quoted someone who said :

>so you shouldn't "just assume" that instance fields are
>accessed at the same speed as values on the stack.)


Which is Java is far from true. locals are much faster than field
instances.

If you ever use IntelliJ code inspector, it jitters at you to convert
nearly all your fields to locals, and to reduce scope to private. Both
these help the compiler generate faster code.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
 
Reply With Quote
 
Daniel Dyer
Guest
Posts: n/a
 
      03-17-2006
On Fri, 17 Mar 2006 19:22:17 -0000, Roedy Green
<(E-Mail Removed) > wrote:

> On Fri, 17 Mar 2006 10:45:43 -0000, "Chris Uppal"
> <(E-Mail Removed)-THIS.org> wrote, quoted or indirectly
> quoted someone who said :
>
>> so you shouldn't "just assume" that instance fields are
>> accessed at the same speed as values on the stack.)

>
> Which is Java is far from true. locals are much faster than field
> instances.
>
> If you ever use IntelliJ code inspector, it jitters at you to convert
> nearly all your fields to locals, and to reduce scope to private. Both
> these help the compiler generate faster code.


I would guess that the intention behind that inspection is more to do with
encapsulation than performance.

Dan.

--
Daniel Dyer
http://www.dandyer.co.uk
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      03-17-2006
On Fri, 17 Mar 2006 19:28:10 -0000, "Daniel Dyer"
<(E-Mail Removed)> wrote, quoted or indirectly
quoted someone who said :

>I would guess that the intention behind that inspection is more to do with
>encapsulation than performance.


It is a happy case where both goals are equally served.

I am moving more toward making things private UNTIL I need the broader
scope. It makes debugging and maintaining easier knowing there are no
outsiders to consider.

I used to make thing package and protected thinking about what you
might want to use in some potential extension.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
 
Reply With Quote
 
Oliver Wong
Guest
Posts: n/a
 
      03-17-2006
"Roedy Green" <(E-Mail Removed) > wrote in
message news:(E-Mail Removed)...
>
> I am moving more toward making things private UNTIL I need the broader
> scope. It makes debugging and maintaining easier knowing there are no
> outsiders to consider.
>
> I used to make thing package and protected thinking about what you
> might want to use in some potential extension.


There was a discussion about this on the OO newsgroup, I think (might
have been comp.object, might have been comp.programming). It was pointed
out[*] that in Java, in a really "disastrous" situation, you could always
use reflection to gain access to a private member, so perhaps it's more
cautious to make things "too" private, and then use reflection in
emergencies, than to make things "too public", and... well... be stuck.

The other nice thing is that using reflections is really inconvenient,
so it makes you think long and hard about whether there might be a better
way to accomplish what you're trying to do.

- Oliver
[*]: Okay, I was the one who pointed that out, so I'm basically just
reiterating my own opinion here.

 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      03-17-2006
"Oliver Wong" <(E-Mail Removed)> writes:
>use reflection to gain access to a private member, so perhaps it's more
>cautious to make things "too" private, and then use reflection in
>emergencies, than to make things "too public", and... well... be stuck.


This kind of access protection might be the holy grail of many
beginner's text books on object-oriented programming.

But I wonder whether anyone has ever seen a situation where a
serious bug or problem was caused by a forgotten »private«
keyword?

I sometimes make variables that are conceptually »private«
»public« in order to emulate something like the C++ »friend«
functions in Java (in a very raw way: All methods are friends,
then.)

One problem with this approach is that the privacy of these
variables is not documented, so they might be misinterpret as
part of the public interface. This shows that one important
duty of »private« is not to protect access under every
circumstance but to serve as documentation of the intent of
the author. Thus, »private« also guides JavaDoc not to
publish the member by default.

 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      03-18-2006
Stefan Ram wrote:

> This kind of access protection might be the holy grail of many
> beginner's text books on object-oriented programming.
>
> But I wonder whether anyone has ever seen a situation where a
> serious bug or problem was caused by a forgotten »private«
> keyword?


I doubt it if happens often. In Smalltalk methods are 'public' or 'private'
only by convention, and it doesn't cause much in the way of problems (given
adequate support for expressing the convention -- an IDE issue, not a language
issue). As a result I can be aggressive about /not/ making things public
unless I'm /sure/ I want to commit to maintaining them across future extension
and redesign. Contrariwise fields are always private (accessible /only/ to the
object, not to other instances of that class), and although I'm quite happy
with that, the Java experience makes me doubt whether that enforced
encapsulation is really buying me very much.

Encapsulation is, IMO, a reflection of the fact that we just /don't care/ about
an object's implementation. We are interested in how it behaves, not in what
other aspects it might leave hanging out which we would rather not look at.
"private" and "package private" are about policing that indifference (a rather
odd concept in itself they do not /provide/ encapsulation.

The bigger risk with making things public, comes with what I call "publishing"
a field or method. I.e. when you (implicitly) commit, to users of your code,
that <such-and-such> a member will continue to exist, and to mean what it means
now. "Published" corresponds, in Java terms, to "public" or "protected".
Premature publication restricts future growth. Unfortunately Java conflates
encapsulation and enforcement, so there is no category which means "you /can/
use this if you have to, but I'm making no promises that it'll still be there
in the next release" -- the nearest you can get is "public"+"deprecated"...


> I sometimes make variables that are conceptually »private«
> »public« in order to emulate something like the C++ »friend«
> functions in Java (in a very raw way: All methods are friends,
> then.)
> One problem with this approach is that the privacy of these
> variables is not documented, so they might be misinterpret as
> part of the public interface.


You could give 'em names like

privateDoFoo()
doFoo_DONT_USE_THIS()
$doFoo$()


> This shows that one important
> duty of »private« is not to protect access under every
> circumstance but to serve as documentation of the intent of
> the author.


Agreed -- as per above.

-- chris


 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      03-18-2006
"Chris Uppal" <(E-Mail Removed)-THIS.org> writes:
>You could give 'em names like
>privateDoFoo()
>doFoo_DONT_USE_THIS()
>$doFoo$()


Right now, I am using names like:

zzField
zzMethod

So they get sorted at the end in the JavaDocs. This does not
look good and the names still show up in the JavaDoc.
So possibly, I could write:

@de.dclj.ram.meta.accessibility.Private field

Then a copy of this would be made to be used as the source for
JavaDoc, and a program will alter this copy to read:

private field

so that JavaDoc will not show it. (It would be more clean to
write a custom Doclet being aware of
»@de.dclj.ram.meta.accessibility.Private«.)

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Are system calls sometimes costlier than library calls? Richard Tobin C Programming 24 11-11-2007 08:52 AM
ods calls business object then method calls ta with output params andy6 ASP .Net 2 06-09-2006 01:54 AM
MoVoIP - FREE MOBILE Inetrnet Phone Calls - FREE Internet Phone Calls ubifone VOIP 0 07-29-2005 04:31 PM
Kataba Functions 1.0 - 100x faster reflective calls for Java Chris Thiessen Java 0 05-05-2004 05:06 PM
Sequence of constructor calls and destructor calls. Honne Gowda A C++ 2 10-31-2003 09:31 AM



Advertisments