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.
A similar benchmark might be appropriate for comparing speed: write an XS
extension to add to numbers, if you want specialize it to add two IVs and
two NVs separately. Now write the equivalent Inline extension. Now run
both through the same set of data where you make a lot of calls to:
$result = add_them($x,$y);
next if $result == $expected_result;
warn "This extension could not add correctly: expected $expected_result, obtained:
$result\n";
The start up times of things that recurse over file systems is dominated
by the details of your hardware and OS (are you running 5400 RPM IDE
drives or 15k RPM Ultra Wide SCSI III's? what file system? etc.)
Likewise the startup time for Tk is dominated by xlib setting up a client
server communication socket (even if it is on the local display).
Note that the above test does not ask of the XS or the inline to do
anything fancy mathematically. On the contrary it asks the routine in
either case to add numbers which is something that nearly any C
implementation should be adequate at (Though some handle IVs and NVs
differently. For example the StrongARM processor has no real FPU and
must do FP math in software emulation with two or more fetches for each
"integer portion" of an FP emulation.) Such a test ought to be dominated
by the speed with which perl can call out to the add_them() routine.
Another thing to consider: Would there be any difference in the purely
functional versus the OO-passing around of blessed hash package names as
in:
my $number_object_x = OO::Add::Them -> new($x);
my $number_object_y = OO::Add::Them -> new($y);
my $result = OO::Add::Them($number_object_x,$number_object_y);
OK?
Peter Prymmer
