> 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