On Wed, Sep 11, 2002 at 12:50:28PM +0200, Leopold Toetsch wrote: > The op_code() function in op_lib_t does look up an op_info_table entry > by the op's full_name. To accomplish this, the current implementation > builds via ops2c.pl basically a static hash table, which get's appended > to core_ops.c and core_ops_prederef.c. > > My proposal is: build a hash table at runtime on the first invocation of > op_code() (which parrot doesn't do).
> If no one has objections I'll send a patch. I like this idea. (but I've no idea of the subtle implications) Where you thinking of building the hash table in one hit using a linear parse over the op names the first time a lookup is requested? An alternative (more complex, may not be worth it) is to perform the hash construction in a lazy fashion: Initialise with a flag that says the hash isn't complete, and a pointer at the start of the linear list. When somewhere requests a name, look in the hash. If found, good Once the hash becomes flagged as complete you stop here, returning not found. Resume the linear search using the pointer. Hash everything you pass by that isn't what you're looking for. If you find it, good. hash it too, save the new pointer, return the result. If you hit the end, flag the hash as complete, return failure. ex::lib::zip is using this approach to scan the directory of the zip file its stuffed in @INC on perl (5.8 or later). I don't know if it's faster, but it feels nicer :-) Nicholas Clark
