>>>>> "Nick" == Nicholas Clark <[EMAIL PROTECTED]> writes:
Nick> On Mon, Aug 09, 2004 at 08:53:27AM -0400, [EMAIL PROTECTED] wrote: >> - MQ has constants. Thousands of them. In the perl module, these get >> mapped to perl XS subroutines (which bloats the symbol table no >> end). For parrot, I'd prefer to use two big hash tables of the type Nick> As in at load time every constant is newXSproto for a new Nick> subroutine, with all created at compile time? No, we're much more gross than that :-) We have some (generated) C routines, one for each type of constant (hex, char, numeric, string) that do a series of string compares and return the right value if found. We then have an AUTOLOAD that tries all of these XS functions in turn. We also add a symbol table entry for each symbol that exists, so there can be compile-time safety when using constants like MQSeries::MQRC_UNKNOWN_OBJECT_NAME Finally, unless the caller turns it off, all of these symbols are imported into the caller's namespace. [ The bane of backwards compatibility. Yuck. ] This allows coders to do if ($rc == MQRC_UNKNOWN_OBJECT_NAME) as opposed to if ($rc == MQSeries::MQRC_UNKNOWN_OBJECT_NAME) at the minor cost of 2 seconds CPU time (SPARC) and 500K RAM every time the module is imported. All this in the name of backwards compatibility - I think the previous maintainer got this part of the design wrong. Nick> Do most constants get used by most code? Most code uses about 10 to 20 constants out of the several thousand that are defined. The real hit is in the default import mode, which imports all these constants *each and every time* the module is used in any script or module. Ouch. Nick> Does the AUTOLOADed approach generated by h2xs use even more Nick> memory or have other problems (eg I know that it doesn't define Nick> its subs with a ($) proto, which means that the constants won't Nick> be inlined by the peephole optimiser) [Ignore whether h2xs will Nick> merely barf, or barf horribly on your headers. I was wondering Nick> about the approach] We don't use h2xs for this. Don't know why - I inherited this code and can only assume that h2xs was tried and failed (in the mid-90s). >> I'd prefer to optimize for smallest data structure size, and am >> willing to take a minor hit at lookup time; looking up constants is >> not performance-critical. Nick> Yes, my questions are more perl5 related, so are sort of really Nick> off topic, but I'm wondering what mistakes the current perl5 Nick> implementation has. Should I have cross posted this to p5p and Nick> used reply-to to prod follows over there? Not sure. I'm not lookig for advice on evolving this module for perl5; it's gross and cumbersome, but I am not about to make deep changes to it. I'd much rather do it right for parrot, specially since I won't have to support that at work (as in: 7*24 beeper support). Doing deep surgery on the perl XS module would require that kind of support burden, as it is extremely heavily used in production, despite all its warts.
