Re: Variable Argument Lists, how to handle?
- From: Christian Borup <borup borup com>
- To: Gtk+ Perl <gtk-perl-list gnome org>
- Subject: Re: Variable Argument Lists, how to handle?
- Date: 28 Oct 2002 17:17:09 +0100
On man, 2002-10-28 at 15:37, Guillaume Cottenceau wrote:
"Marin Purgar" <m purgar extracom de> writes:
What should be the preffered way to handle the methods accepting variable
For now some of the implemented methods use perl 'proxy' methods which are
converting arrays/hashes to references and then passing them to the
underlaying inline function/method.
The advantage of that is to move some code out of C and have it
in Perl in the .pm; my opinion is that the most perl code we
have, the better.
You argument does make some sense. But the code needed to manipulate the
array/hash references are of equivalent complexity to the stack
But anyway I have no problem with using perl proxies. If they turn out
to be too inefficient moving them to C should be no problem.
I'm seriously considering the ability to have something automatic
(or not) to convert all the Inline .c into one large .xs, at
compilation time (e.g. not in the CVS) (at the end of the
development, or at least when we have something usable) so that
we don't have a large number of .so files, but only one, because
I suppose/hope this is why gtk2-perl takes more memory than
gtk-perl, and has a much higher program startup time.
If we begin to use Inline-specific things in the .c, it would
make this far more difficult.
Isn't it possible to make Inline generate just one .so?
Also folding all the .pm's into just one Gtk2.pm might speed things up a
bit. But really only a benchmark can tell. Also it would rid the
scripter from having to "use" every widget used, not even C programmers
have to endure that.
The old gtk-perl useses a lot of tricks to stay fast. Maybe you can get
some hints there.
] [Thread Prev