The Artima Developer Community
Sponsored Link

Java Community News
Lorenzo Puccetti on Event-Driven Architecture

24 replies on 2 pages. Most recent reply: Sep 19, 2007 9:15 AM by one reader

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 24 replies on 2 pages [ « | 1 2 ]
Nick Evgeniev

Posts: 16
Nickname: nevgeniev
Registered: Aug, 2007

Re: Lorenzo Puccetti on Event-Driven Architecture Posted: Sep 17, 2007 12:36 AM
Reply to this message Reply
Advertisement
hi,

>
> And let's not post unsubstantiated claims, ok? ;)
>
> Feel free to post an example of the performance problems
> that interfaces cause or some reference that backs up your
> claim.

Just I said I see no points on starting yet another flawed micro benchmark flame. And your benchmark code is flawed in many ways, it's even hard to say what it actually measures :).
I suggest you to take a look at the following article of, well, much more respected author than me ;)

http://www.ibm.com/developerworks/library/j-jtp12214/

And I still insist that interface calls are slower to dispatch. Just think this (much simplified) way -- to lookup method of the concrete class you have to perform one VMT lookup as methods of the concrete class are ordered in a single table, to lookup interface method you have to perform *several* lookups at least in interface method table and class method table. There are a lot efforts were put to optimize interface method lookups but all what can be done is corner cases optimizations and various tricks in building interface method tables. so strictly speaking lookup time can be ordered that way:
interface >= class >= class + final/private method modifier

well to sum up -- in real project targeting high volume realtime data you might want to keep interface calls constant over execution path (independent of data volume) as well as keep constant (independent of data volume) object allocation, or at least adjust "new generation" size to handle peak loads (in case you insist for some reason on creating object "new T()" for each event.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Lorenzo Puccetti on Event-Driven Architecture Posted: Sep 17, 2007 6:27 AM
Reply to this message Reply
> Just I said I see no points on starting yet another flawed
> micro benchmark flame.

You are suggesting a micro-optimization. What other kind of benchmark would be applicable. Actually, to be correct, you are suggesting a nano-optimization.

> And your benchmark code is flawed
> in many ways, it's even hard to say what it actually
> measures :).

I think you don't understand it.

> I suggest you to take a look at the following article of,
> well, much more respected author than me ;)
>
> http://www.ibm.com/developerworks/library/j-jtp12214/

I've read it before.

> And I still insist that interface calls are slower to
> dispatch. Just think this (much simplified) way -- to
> lookup method of the concrete class you have to perform
> one VMT lookup as methods of the concrete class are
> ordered in a single table, to lookup interface method you
> have to perform *several* lookups at least in interface
> method table and class method table. There are a lot
> efforts were put to optimize interface method lookups but
> all what can be done is corner cases optimizations and
> various tricks in building interface method tables. so
> strictly speaking lookup time can be ordered that way:
> interface >= class >= class + final/private method
> modifier

I didn't say it doesn't take longer. I said it's not significant. My test shows that the interface does take longer and consistently so. It's just that the difference is measured in nanoseconds.

> well to sum up -- in real project targeting high volume
> realtime data you might want to keep interface calls
> constant over execution path (independent of data volume)
> as well as keep constant (independent of data volume)
> object allocation, or at least adjust "new generation"
> size to handle peak loads (in case you insist for some
> reason on creating object "new T()" for each event.

You still haven't provided anything to back this up. No demonstration, no reference.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Lorenzo Puccetti on Event-Driven Architecture Posted: Sep 17, 2007 6:35 AM
Reply to this message Reply
> There are a lot efforts were put to optimize interface
> method lookups but all what can be done is corner cases
> optimizations and various tricks in building interface
> method tables.

If that is the case it should be a fairly simple matter of defeating these tricks.

> so strictly speaking lookup time can be
> ordered that way: interface >= class >= class +
> final/private method modifier

I don't see much difference there either. And the last time I looked up this information in the VM spec, it's not required that the VM optimize calls bound to final types.

Just trying to sound like you really know what you are talking about is not enough.

Dele Taylor

Posts: 2
Nickname: del
Registered: Mar, 2003

Re: Lorenzo Puccetti on Event-Driven Architecture Posted: Sep 17, 2007 12:42 PM
Reply to this message Reply
> Actually using concrete implementations such as ArrayList
> in an interface isn't such a good idea. Using List or
> Collection is much better. This let's the caller decide
> what kind of list or collection suits the need best.


Bengt--I put ArrayList because I wanted to mirror the array semantics in the previous post. Like many others I like to loop through lists using for loops, probably not a good idea if it's a LinkedList. I agree that using a Iterator is a good idea--as long as you only need to traverse the list once and in order.

I think part of a developer's job is deciding how to balance the tradeoffs Nick has pointed out.

Cheers,
Dele

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Lorenzo Puccetti on Event-Driven Architecture Posted: Sep 17, 2007 12:44 PM
Reply to this message Reply
> passing arraylist does to things:
> 1. it's a concrete class so calls to it's methods are
> faster

Admittedly this can vary significantly from VM to VM. On the Sun VM, the difference has been reduced "to almost nothing" (if I remember the quote correctly).

> 2. you don't need to create Iterator to iterate over it,
> but can use plain old for instead (avoiding creation of
> unnecessary object)

Yes, that is the List interface. It extends Collection.

> 1. you have to create all the events placed to the list,
> while passing iterator allows you to use flyweight pattern
> or its variants.

Again, if it is the List interface, then this is not true.

Peace,

Cameron Purdy | Oracle
http://www.oracle.com/technology/products/coherence/index.html

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Lorenzo Puccetti on Event-Driven Architecture Posted: Sep 17, 2007 2:26 PM
Reply to this message Reply
> > passing arraylist does to things:
> > 1. it's a concrete class so calls to it's methods are
> > faster
>
> Admittedly this can vary significantly from VM to VM. On
> the Sun VM, the difference has been reduced "to almost
> nothing" (if I remember the quote correctly).

Do you have any guess what the worst case scenario might be? I can't recall ever reading or hearing about someone with a performance issue that was resolved by changing interfaces to concrete classes. I'm sure I haven't seen or heard any such thing in recent years.

Maybe it's a concern. I just see no evidence for it.

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Lorenzo Puccetti on Event-Driven Architecture Posted: Sep 17, 2007 3:54 PM
Reply to this message Reply
Well, you have articles like this one from 1997:

http://www.cybergrain.com/tech/writing/efficient-java.html

It states "interface methods are slow".

OTOH, IBM points out that interface based method invokes can be very cheap:

http://domino.research.ibm.com/comm/research_people.nsf/pages/dgrove.oopsla01.html

Peace,

Cameron Purdy | Oracle
http://www.oracle.com/technology/products/coherence/index.html

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Lorenzo Puccetti on Event-Driven Architecture Posted: Sep 17, 2007 4:17 PM
Reply to this message Reply
> Well, you have articles like this one from 1997:

Cameron - Nearly every Java optimization trick from 1997 is either useless or outright wrong.

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Lorenzo Puccetti on Event-Driven Architecture Posted: Sep 17, 2007 4:59 PM
Reply to this message Reply
Hence my pointing it out ;-)

one reader

Posts: 2
Nickname: onereader
Registered: Sep, 2007

Re: Lorenzo Puccetti on Event-Driven Architecture Posted: Sep 19, 2007 9:15 AM
Reply to this message Reply
>> Well, you have articles like this one from 1997:
>> http://www.cybergrain.com/tech/writing/efficient-java.html

What article are you talking about ?
The article written by Lorenzo is all about writing a timely event driven solution for a single process application
(peraphs running on one of those fancy multi core machines)
using the latest JDK java.util.concurrent classes.

Flat View: This topic has 24 replies on 2 pages [ « | 1  2 ]
Topic: Anders Norås Releases Quaere, a LINQ-like DSL for Java Previous Topic   Next Topic Topic: Sun Releases NetBeans IDE 6.0 Beta

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use