[RFC] building core.ops op_hash at runtime
Leopold Toetsch
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).
This would currently:
- save ~ 2*1500 lines of genderated source code
- save - according to nm 2*13 KB per static executable
- save 50 % lookup time because of fully hashing the opcodes full_name
- have no influence on parrot itself, because parrot doesn't use this
function.
testing op_code for 889 ops 10000 times:
current: real 0m8.674s
mine: real 0m3.827s
The current only users of op_code() are the debugger (PDB_eval), pxs.c
and imcc.
If no one has objections I'll send a patch.
leo
Nicholas Clark
> 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
Leopold Toetsch
> On Wed, Sep 11, 2002 at 12:50:28PM +0200, Leopold Toetsch wrote:
> I like this idea. (but I've no idea of the subtle implications)
There are only PDB_eval, pxs.c and imcc as users currently, I can't
really see subtle implications whatsoever.
> 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?
Yes, ecactly this.
> An alternative (more complex, may not be worth it) is to perform the hash
> construction in a lazy fashion:
This is a nice approach but by far not worth the effort. Might be to
reconsider, when we have 10^5 ops, sorted by there usage count ;-)
> ... I don't know if it's faster, but
> it feels nicer :-)
Yes, in above case.
> Nicholas Clark
leo