[MUD-Dev] Re: Question on c++ switch optimization, and parsers in general.

Ben Greear greear at cyberhighway.net
Mon Feb 8 22:32:44 New Zealand Daylight Time 1999


Adam J. Thornton wrote:
> 
> On Mon, Feb 08, 1999 at 08:29:46PM -0700, Chris Gray wrote:
> >     - emit an inline table containing offsets to the code to be executed.
> >       Table is directly indexed by a multiple of the switch value,
> >       usually with a range-test to handle the default. A variant is
> >       to have branch instructions in the table, and to branch to
> >       the appropriate one which then branches to the final code.
> 
> The computed GOTO lives!
> 
> My approach would be: write it however it is easiest for you, the author,
> to understand.
> 
> If it turns out to be unacceptably slow, and if profiling the execution
> shows that that *is* the bottleneck (both of which I consider unlikely),
> then think about changing it and worry about how your compiler is doing it.
> 
> Adam
> --
> adam at princeton.edu
> "There's a border to somewhere waiting, and a tank full of time." - J. Steinman

Thanks for all the interesting discussion!

My new plan to do things is this:
Going to write a command spec file, which will contain well-formatted
entries
of aliases, help_keys, and actuall code to satisfy the command.

Then, I'm going to run it through a code-generator to generate c++ code.
A class will be generated for each command, with an execute() command
containing
the actual code mentioned just above.  An instance of each class will be
put
in an array (indexed by an enum, just cause I like enums, and I can
easily
generate one at this point anyway).

So, once I get the enum though what-ever hashing method I come up with,
it will be a simple array-lookup to find the object that knows how to
execute the code.  With my current approach, I expect an average of
10-20
strncasecmp's per command, which I can live with.  I can always optimize
that
down the road, but I'm sure stuff like AI code will drown it anyway.

This (I think, not done yet) arrangement should give me the goals I set
out for:
	*  Easy to add aliases, because I want to make it multi-lingual
eventually.
	*  Quick lookup time.
	*  Help key paired with command so I don't have to edit both in
separate code...
	*  Easy to modify en-masse (through code generation).
	*  I don't have to hand type a bazillion minute classes with one boring
	   method, cause it's generate by magic now!

I will of course publish all this code as soon as it compiles :)

Ben

--
Ben Greear (greear at cyberhighway.net)  http://www.primenet.com/~greear 
Author of ScryMUD:  mud.primenet.com 4444        (Released under GPL)
http://www.primenet.com/~greear/ScryMUD/scry.html




More information about the MUD-Dev mailing list