[MUD-Dev] Text Parsing

[Matthew Mihaly]

On Wed, 9 Jun 1999, J C Lawrence wrote:

> On Wed, 9 Jun 1999 16:21:28 -0700 (PDT) 
> Matthew Mihaly <diablo at best.com> wrote:
> 
> > Actually, on that note generally, I have read some talk on here,
> > in the past, about how some of your servers can handle a LOT of
> > users online at once without having speed problems. 

> 
> > How the heck do you manage that? 
> 
> Careful design mostly.  I know what things cost, how much they cost,
> and how often I absolutely have to do them.  This is one of the few
> areas where all that CS math you (should have) done in grad school
> comes in *really* handy, but is still not really necessary.

Yes, this is definitely a problem for me. 1) I did not go to grad school.
2) My undergrad degree is in political philosophy. 3) Except for some
BASIC in high school, I had never coded a thing before starting Achaea. It
honestly never occurred to me, until about a year ago, that speed would
EVER be a problem in a text game. No graphics I thought? Hell, how much
processing power can that take?? *doh*

> 
> > We use an interpreted engine (which I realize is inherently
> > slower)...
> 
> That's a dangerous and often massively misleading assumption.
> Interpreted languages need not be either slow or performance
> bottlenecks.  LP and BatMUD demonstrate this rather clearly.
> LambdaMOO demonstrates rather clearly that this _can_ be a problem
> given poor design and implementation.  BatMUD shows part of the
> other side: that given good and careful work, the performance hit is
> a strawman.

Yeah, I was a wiz on batmud ages ago. That's what I was thinking of when I
was questioning our player problem (as back when I played them, they'd
have 250 people online, and people lining up to get in. No idea what it's
like now). I just assumed that interpreted languages would be slower I
guess becuase of the extra layer.

> 
> > I suspect that our player routines (mainly movement) tend to be
> > significantly more complicated than most muds (again, mainly
> > movement, due to the enormous number of database searches that
> > need doing to check for all sorts of stuff everytime someone
> > moves)...
> 
> I smell sloppy thinking here.  Yes, there is good reason for having
> motions trigger cascading state checks.  I do it myself, and I
> suspect do it to a far greater degree than you do (I've counted over
> 2,000 state checks resulting from a single most-pessimal move).  No,
> there is no reason for those state checks not to short circuit
> extremely cheaply in the common cases.  A heck of a lot of the time
> you can determine far more cheaply whether or not you need to make a
> variety of checks, than you can do the checks themselves.

Yes, you're probably right about the sloppy thinking. I don't really know
what I'm doing as far as elegant coding goes. Also, I'm not quite sure
what a state check is, but I'm guessing it is checking the state of a
particular piece of data?

One particularly serious problem that I suspect we have are players
following other players around. Right now, a following player goes through
nearly every routine that the leading player goes through, effectively
doubling the time it takes. If you've got 5 players following a single
player, it can get ugly, especially with those blasted speedwalks.

Anyway, thanks for the advice! 
--matt




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev