[Kde-bindings] playground/bindings/kimono

[Richard Dale]

On Wednesday 21 March 2007, Arno Rehn wrote:
> Am Mittwoch, 21. März 2007 schrieb Arno Rehn:
> > Am Mittwoch, 21. März 2007 schrieb Richard Dale:
> > > I think it would be quicker and easier to special case these methods on
> > > the C/C++ side. Then we would probably only need to do a string
> > > comparison on the method name, and rearranging the smoke stack is
> > > easier there too.
> >
> > Yes, you're right. But I wonder why it causes such a high overhead by
> > doing this in C#. Once it is compiled by the JIT it should work rather
> > fast, shouldn't it?
>
> Just did it in C++ again and now it doesn't create any additional overhead
> in your 't14 performance check' anymore. It's just the same as without
> additional code for instance operators. Patch attached.
Yes, that looks pretty good to me - lets commit it. Also it will work with all 
types of argument which the C# version didn't.

I repeated a test with the command 'time mono t14.exe' and did five shots at 
force 40 and got these results:

With no 'IsInstanceOperator':
real    1m5.439s
user    0m20.385s
sys     0m0.392s

With 5 calls of 'IsInstanceOperator':
real    1m8.132s
user    0m30.162s
sys     0m0.276s

So the overhead with this measurement is more like 10% per IsInstanceOperator 
call. I have a 1.8 Ghz dual core MacBook, and it's pretty amazing that 
tracking the the shot and redrawing a simple game is taking 20% of powerful 
processors. It's really too early to start optimizing Qyoto until it's 
feature complete (which it nearly is), but it's quite important to not make 
it any worse than it already is.

The cannon game seems as good a test as anything else. It also leaks memory, 
and I wonder if it's worth adding debug logging for the GCHandle alloc and 
free calls as I suspect they're not all being freed.

-- Richard