Peter Prymmer wrote:
>
> On Thu, 21 Jun 2001, Brian Ingerson wrote:
>
> > ----- Forwarded message from Nathan Torkington <[EMAIL PROTECTED]> -----
> > Brian Ingerson writes:
> >
> > > Putting code in a separate file is a possibility, but not the
> > > norm. Here is the canonical form:
> >
> > My first reaction is: ick. Won't that confuse the crap out of
> > your editor?
> >
> > > I'm really glad you are. Now if we can just get Nick to start
> > > writing perl-xs examples using Inline... :)
> >
> > Are there any tangible benefits to rewriting XS code to use Inline,
> > e.g. speed, or are the benefits mostly in maintainability?
>
> In addition to speed there is also the issue of memory: can you point to a
> perl XS extension and a functionally equivalent Inline perl extension and
> demonstrate that the latter mallocs less, takes up less RAM or virtual
> memory etc. on a "reasonable" OS or collection of platforms. Since Perl
> by and large has no qualms about trading memory to gain speed I might be
> interested in say re-writing bits of mod_perl that needed to run for a
> long time without growing in size.
OK. I think there's still some basic confusion. Inline *IS* XS. It's all
a very sophisticated automation trick. There is very little new software
involved. Inline just takes what I consider to be the best XS practices
and makes them happen automatically for the user. The benefits of this
end up being more socialogical than technical. It seriously lowers the
barrier-to-entry into this realm. The trade-off is that you give up full
control for ease of use. To many folks, the latter is very important.
That's why people use Perl instead of C, and C instead of Assembly.
But comparing Inline to XS in speed and memory terms is a little fuzzy.
Everything depends on the quality of the typemap code, and this will be
the same code in either usage. You really only need to look at the XS
generated by Inline to understand what it's doing. Basically Inline
always generates a typemapping wrapper, whereas in XS you can use a CODE
or PPCODE section.
Try running:
perl -MInline=info,force,noclean inline_script.pl
There will be output telling you where to find the generated build
environment complete with .xs file. Poke around.
---
If you have a stable project written with XS, there is no reason to
switch to Inline. You've already done the work. There will be no
performance or memory improvements.
But if you're starting something new, or want to share your code, or
want to get other people to start maintaining your project, Inline has
some real benefits.
Hope this helps, Brian
PS Neil Watkiss just pointed out to me that if I allowed the C 'inline'
keyword to be used, the compiler could inline the C function in the XS
wrapper. But he also points out that the complexity of getting from Perl
to an XSub is an order of magnitude greater than the extra C function
call.
--
perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf
("Just Another %s Hacker",x);}};print JAxH+Perl'
