May I ask what you are using to compose you messages. I am unable to format them correctly in Gecko. I am not havin any trouble with any of the other posters. Can someone tell me if they are getting formatting issues with Duncans email or do I need to change my reader.

> And so the *only* time we drop down to writing actual C code
> is if a native database driver does something funky with its interface
> that NCI doesn't understand;

You are correct. The _only_ time we will use C is when we are unable to use IMC

> I also see a big advantage here where the dichotomy of the current DBI
> core, one in XS and one in pure Perl 5, will go away.  There would be
> a single core instead.

I do not see the Pure Perl driver and the XS version as contradictory. I see them as complimentary.

> So, some more questions:

> 1. Is my above understanding correct?

> 2. One of DBI's touted strengths is its speed.  So while Parrot itself
> is being designed and worked over to deliver maximum performance of
> all PASM/IMCC code, is it going to be enough such that a completely
> interpreted PDBI framework will have comparable performance to the old
> DBI?  Or do you see the  project sacrificing a fair amount of speed
> (at least in the short term) by not being written mainly in C?

I think the only answer here is, we will just have to wait and see. The DBI is very fast and in reality if you really need something that much faster you should probably be using raw C or whatever other lib the database has provided.

The DBI's speed is not really a touted strength its more of a fact. For the record, a lot of the issues people have with the DBI's speed is through not using it properly. They also mistakenly blame the module or the drivers when it is actually Perl itself that is the problem.

As for Parrot, the guys are making it as fast as they possibly can but unlees someone here has a crystal ball ;-) I doubt we would be able to guess for or against at this stage.

> I mean, in my mind all the gains we would have from going all Parrot
> native far outweighs any down sides.  But my point in asking is
> whether anyone sees this as a concern such that they may decide to
> move parts of PDBI (core particularly) to C later on.  Or is such a
> move going to be expressly avoided in principle?

We will have to see. If performance is terrible then who knows, if it is
fantastic we might see someone write a C core anyway. There is more than one way to do it ;-)


Harry



Reply via email to