[Kde-bindings] playground/bindings/kimono

Arno Rehn arno at arnorehn.de
Wed Mar 21 16:53:06 UTC 2007


Am Mittwoch, 21. März 2007 schrieb Richard Dale:
> On Tuesday 20 March 2007, Arno Rehn wrote:
> > SVN commit 644738 by arnorehn:
> >
> > * Made instance operators work
>
> OK good this is quite simple to implement. I wasn't sure that checking for
> operator methods with one arg was a good way of telling if it was an
> instance method, but it seems there aren't really any static ones with one
> arg and it does work:
>
> rbqtapi -roperator | grep static |grep -v ','
>         static const QPoint QGlobalSpace::operator-(const QPoint&)
>         static const QPointF QGlobalSpace::operator-(const QPointF&)
>
> But when I ran my 'performance test' which consists of starting tutorial
> t14, setting the force to 40 and firing a shot while watching the cpu
> consumption with top, I noticed it uses quite a bit more with this change.
> Up to 38% of cpu from about 22% before.
Just did that myself and also recognized a slightly higher overhead, but only 
from 19.6% to 22.3% - so not so heavy as yours. I don't know what hardware 
you have, I have here an AthlonXP 3000+ and 768MB RAM.

> I changed the code to set a boolean 
> to save the value of the test to avoid doing it twice per method call. Then
> I tried duplicating the IsInstanceOperator call so it was tested 5 times
> and found that t14 ran with about twice the cpu load as with no calls at
> all. So it looks like there is quite a big overhead per method call.
>
> 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?

-- 
Arno Rehn
arno at arnorehn.de



More information about the Kde-bindings mailing list