[Kde-java] Re: [Kde-bindings] Using a custom RealProxy to implement a C# SMOKE adaptor

[Richard Dale]

On Tuesday 26 August 2003 09:34, Gert-Jan van der Heiden wrote:
> Doesn't SmokeInvocation need to use jni too, if it wants to access Smoke?
> Then the proxy invocations take even longer...
Yes, but the dynamic method overloading resolution will take longer than the 
bare method call either via JNI or via Proxies. The marshalling overhead will 
be identical to the previous bindings.

> If proxies would be a performance problem, can't kalyptus do that part in a
> static. I mean something like:
>
> public class QFont{
> private SmokeInvocation smokeInvocation;
>
> public QFont(){
>    this.smokeInvocation = new SmokeInvocation(this);
> }
>
> public void setSize(int size){
>    this.smokeInvocation.invoke("setSize",{new Integer(size)});
> }
> }
>
> That would skip the proxy part, and the invocation to Smoke is still in one
> place. Of course the "setSize" param isn't a Method object as the proxy now
> expects.
I think it would be better to wait until there is more of the runtime to 
measure, otherwise we might be optimizing the wrong thing too early. Because 
the bindings are entirely autogenerated it will be relatively easy to change 
the code generation to try out the different speed up ideas.

> Here are the proxy tests on my machine:
>
> __________machine info_______________
> gertjan at KirkMachine:~/build/test/proxy> cat /proc/cpuinfo
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 8
> model name      : Pentium III (Coppermine)
> stepping        : 6
> cpu MHz         : 598.694
> cache size      : 256 KB
>
> gertjan at KirkMachine:~/build/test/proxy> java -version
> java version "1.4.2"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
> Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)
>
> gertjan at KirkMachine:~/build/test/proxy> gcj --version
> gcj (GCC) 3.3 20030226 (prerelease) (SuSE Linux)
> Copyright (C) 2002 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> _____________JNI____________
>
> gertjan at KirkMachine:~/build/test/jni> time java Doit
>
> real    0m2.819s
> user    0m2.760s
> sys     0m0.040s
>
> ____________proxy____________
>
> gertjan at KirkMachine:~/build/test/proxy> time java Doit
>
> real    0m4.297s
> user    0m4.170s
> sys     0m0.060s
>
>
> gertjan at KirkMachine:~/build/test/proxy> gcj *.java -o doit --main=Doit
> gertjan at KirkMachine:~/build/test/proxy> time ./doit
>
> real    0m42.661s
> user    0m41.510s
> sys     0m0.070s
> gertjan at KirkMachine:~/build/test/proxy> time ./doit
>
> real    0m41.661s
> user    0m41.490s
> sys     0m0.040s
I think the jdk 1.4.2 proxy implementation screams - only half the speed of 
JNI is actually really fast. When we last discussing the speed of gcj 
proxies, I hadn't noticed a post about the current implementation being 
interpreted, rather than compiled - that explains why it's so slow. As soon 
as gcj were to use compiled proxies there would be a big speed up.

-- Richard