[ nice-Bugs-888398 ] strange value dispatch performance

"SourceForge.net" <[email protected]>
Newsgroups gmane.comp.lang.nice.devel
Message-ID <[email protected]>
Bugs item #888398, was opened at 2004-02-01 02:40
Message generated for change (Comment added) made by arjanb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112788&aid=888398&group_id=12788

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Isaac Gouy (igouy)
Assigned to: Nobody/Anonymous (nobody)
Summary: strange value dispatch performance

Initial Comment:
1) Strange difference in dispatch performance for enum 
objects compared to strings or ints?

   obj      string    int
   265     125       94
   360     94        109
   453     94        109
   4672   125       109
   8891   109       110

2) If you uncomment the section between

   // ##### START open comment here

   // ##### END

then 

\Nice\evaluation\valuedispatch>nicec --sourcepath .. -a 
t.jar valuedispatch
nice.lang: parsing
valuedispatch: parsing
valuedispatch: typechecking
valuedispatch: generating code
valuedispatch: linking

An exception has occured in the compiler
Please fill-in a bug report at the following webpage:
http://sourceforge.net/tracker/?
func=add&group_id=12788&atid=112788

Stack trace:
Exception in thread "main" java.lang.OutOfMemoryError


Nice compiler version 0.9.6 prerelease (build 2004.01.31, 
17:05:23 UTC)



----------------------------------------------------------------------

>Comment By: Arjan Boeijink (arjanb)
Date: 2004-02-02 22:43

Message:
Logged In: YES 
user_id=688815

String comparison with equals will always be an order of 
magnitude slower than comparing ints.

That the results for 1 and 3 argument are so favorable for 
ints is only because you make it so easy for the jvm to 
optimize. Try getting the arguments from some (global) array 
and make the implementation body not empty (incrementing a 
counter or something)

A better test for the quality of generated dispatch code is 
looking at time related to the number of method 
implementations.

----------------------------------------------------------------------

Comment By: Isaac Gouy (igouy)
Date: 2004-02-02 21:58

Message:
Logged In: YES 
user_id=536291

The suggestion that, in practice, we are unlikely to see value 
dispatch on 9 method parameters seems reasonable to me. 

As we are likely to see value dispatch on one or two 
parameters, differences in peformance according to 
parameter type become interesting.  (Especially when we 
have replaced the switch statement by method dispatch.)

If the differences result from jvm performance, looks like I'll 
be using int constants instead of strings for value dispatch. 


One- Enum/int: 5.29  Object/int: 3.58        String/int: 
89.86       int: 546ms
Three- Enum/int: 2.94  Object/int: 2.34        String/int: 
46.09       int: 3531ms
Five- Enum/int: 1.07  Object/int: 1.06        String/int: 
6.02        int: 42313ms
Seven- Enum/int: 1.18  Object/int: 1.18        String/int: 
7.39        int: 49047ms

----------------------------------------------------------------------

Comment By: Arjan Boeijink (arjanb)
Date: 2004-02-02 15:45

Message:
Logged In: YES 
user_id=688815

I think you are testing the inlining and optimizing capabilities 
of the jvm here.

Can this one be closed since you opened another for the 
OutOfMemoryError?

----------------------------------------------------------------------

Comment By: Isaac Gouy (igouy)
Date: 2004-02-01 23:50

Message:
Logged In: YES 
user_id=536291

So I tried that again, using 
   class Val {}
   let Val One = new Val();
instead of the enum

Similar when there are no more specific implementations:
   266  109  110
   344  93  110
   468  94  110
   4656  94  109
   8844  109  94

When there are more specific implementations, matching on 
Strings is an order of magnitude slower than matching on ints:
   2875  49469  515
   10422  159953  3593
   45016  254625  42641
   57640  358313  49281
   70484  456344  49625



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112788&aid=888398&group_id=12788


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.