develooper Front page | perl.perl5.porters | Postings from January 2006

[RFC] XS::Connect

Thread Next
Chase Venters
January 31, 2006 23:12
[RFC] XS::Connect
Message ID:
	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?

Chase Venters

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About