[Kde-perl] Holiday musings

[Germain Garand]

Le Samedi 30 Novembre 2002 23:35, Ashley Winters a =E9crit :
> At the end of my message, I said the multimethod dispatch would be
> moved into Perl. As part of my XML format, I would provide a unique ID
> for each method to be called, and that "static" id would be used from a
> static language to call the appropriate method.

Providing function ids looks fine, but not really flexible (what about pe=
ople=20
parsing the headers with different #defines ? ). Why not rather trying to=
=20
keep the two systems (Corba like and static) so that people can choose th=
e=20
best binding strategy for their needs ?
That would be the ultimate tool !
Maybe that's what you meant, but that's not clear to me. If Perl needs=20
multimethod dispatch, so will Ruby for instance. So why moving it to Perl=
 ?

Also, it would be nice to keep binary compatibility in mind.
Smoke made it into KDE 3.1... that's a wonderful opportunity for gaining=20
adopters... pissing them off by breaking the binary compatibility or lett=
ing=20
the curent version rot while the work continue elsewhere would be sad.

> Well, C# wouldn't need to do a binary search. Static language, static
> method ids. PerlQt might benefit from a better algorithm, though.
> Perhaps a switch() on methodName[0] could speed things up by 4 or 5
> strcmps.
>
>
It certainly would help. Qt is hudge and it takes about 0.5 ms on my 800 =
Mhz=20
box to find a method by name. Also the numeric binary search through the=20
method table is not efficient, since it tries to match both the classid a=
nd=20
the methodid.
Now,  I've just spent some hours profiling a bit the PerlQt code and I've=
=20
changed my mind about that : with the dead simple "memoize-like" cache, t=
he=20
lookup overhead is no more significant. You can afford to be slower for t=
he=20
first call of a 100000 loop :)

> However, the long binary search isn't even .1% of the performance
> problem of PerlQt-3.002. Another 90% of the problem is &do_autoload in
> Qt.pm, which needs to be rewritten in C.

I'm not sure if it is a major bottleneck. When a method is cached, do_aut=
oload=20
returns almost immediately...=20
I wonder if turning the memoize cache into C++ code wouldn't be more=20
rewarding.
Anyway, I paste below the results of a benchmark  I ran when looking for=20
optimizations. It looks pretty decent, actually !
(well, except the dreadful object creation, aka "Foo" calls "Foo->new()" =
calls=20
"Qt::base::new" calls "Foo->NEW()" calls some closures calls XS Autoload=20
calls do_autoload, etc ... *gasp*)


Benchmark started on lun d=E9c 2 14:58:30 2002

Timing 20000 method calls...820ms

Timing 20000 static enum calls (no parenthesis)...631ms

Timing 20000 static calls (with parenthesis)...659ms

Timing 20000 object creations...3196ms

Timing 20000 object deletions...890ms

Timing 10 ambiguous method calls (without cache)...15ms

Timing 10 ambiguous method calls...3ms