Front page | perl.perl5.porters |
Postings from January 2006
From: Chase Venters
January 31, 2006 23:12
Message ID: firstname.lastname@example.org
I'm using DateTime heavily in a large web application. I was a bit
underwhelmed by the performance of the thing and started looking into the
possibility of moving more of the code into XS. I noticed the rather curious
admission in the TODO document that the author's first attempt to move
duration math into XS had resulted in (surprise) slower code.
I talked briefly with them about it on the mailing list, and they
(guestimated?) that the slowdown was incurred from crossing the XS/Perl
barrier. (Unfortunately, I haven't had time to really find out if this is
true yet. I greatly apologize if I'm way off base).
This led me to thinking about clever ways to let module trees like everything
in the DateTime:: namespace locate loaded XS components and somehow
circumvent the overhead of going through Perl for simple function calls.
So I figure that a fast implementation of something like DateTime is going to
be mostly in XS, and would probably be wise to store certain data in a C
This led to me wondering if there was the possibility that XS modules could
learn of the existence of XS versions of other modules it's designed to work
with an exchange a vtable. The basic idea is that an XS module could create
some arbitrary vtable (c struct) and attach some kind of opaque perl data
type to it.
The modules could have functions to accept this opaque data type. XS code
receiving an instance of this opaque data type could easily convert it back
into a pointer to a cstruct. (The purpose of the opaque type is to prevent
pure perl code from having a means by which it can crash perl).
At this point, XS modules that want to make lots of calls to some function in
another XS module can do so by simply dereferencing the pointer to the
function as opposed to asking Perl to go to its symbol table, etc.
(Macros could be provided for the C code to do real Perl calls if handed a
vtable full of NULLs, which could cut down on any code duplication).
My understanding of all this, at this point, is based on having written a
small amount of XS code and a lot of Perl code. I've cracked the lid on the
internals and peeked around a bit to know at least how it's organized. I
don't claim to be very proficient in Perl internals yet.
So I'm merely curious as to a few things:
1. Am I way off base?
2. Would people be interested in an implementation?
by Chase Venters