> On a platform with a halfway decent JIT, a pure-PASM implementation
> could be as fast as an op-based one, given liberal use of the non-PMC
> registers. Maybe faster--no need to transcode to ASCII, extract a C
> string, or hack around platform X's quirks. And I'd imagine that the
> Parrot standard library would be written to be as fast as possible.
ok, well cool. We'll see then.
> Besides, how fast does your date handling really need to be? I mean,
> *really*? Are you formatting eleventy billion dates in a tight loop or
> something?
yes.
Its a major issue/pain in database conversions, and in funnelling data
from system to system - in my case, approximately 4 date conversions
for each of 2.5 billion rows on different systems, some of them live production.
Dates converted from one system standard oracle format to another oracle format.
>From mysql to db2. db2 to oracle. Date comparisons between different formats.
(and yes, I have rolled 'my own' wrapper for handling this stuff. I use it
both from perl and generated c to do the conversions. However, I'm sick of
rolling my own stuff to 'supplement' what IMO should be native to perl itself.)
In any case, like I said, I don't have any problem with standard
libraries handling this stuff; as long as whatever library is:
a) reasonably fast - ie: within 20% of C
b) just as robust as the standard system stuff
c) has a reverse formatting function, going back to seconds from dates.
d) is standard - handles 95% of necessary date manipulations
e) has a tight memory footprint.
I think its a waste to reimplement everything though. There is a
LOT THERE in libc which could be leveraged. And it definitely would be a
good idea for parrot to make dates almost as low level an item as
strings,numbers, etc - ie: native datatypes or close to native. A
formatting op which tied numbers to strings would do that quite nicely.
Ed
