Yes, thanks for hte clarification. I'll leave my XS alone.
It ain't broke, don't fix it :)
=========+=========+=========+=========+=========+=========+=========+
___ _ ____ ___ __ __
/ _ )(_) / /_ __ / _ \___ _/ /_/ /____ ___
/ _ / / / / // / / ___/ _ `/ __/ __/ _ \/ _ \
/____/_/_/_/\_, / /_/ \_,_/\__/\__/\___/_//_/
/___/
Texas Instruments ASIC Circuit Design Methology Group
Dallas, Texas
214-480-4455
[EMAIL PROTECTED]
=========+=========+=========+=========+=========+=========+=========+
On Thu, 21 Jun 2001, Brian Ingerson wrote:
> 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'
>
