[MUD-Dev] Text Parsing
J C Lawrence
claw at varesearch.com
Thu Jun 10 19:46:18 CEST 1999
On Wed, 9 Jun 1999 20:34:12 -0700 (PDT)
Matthew Mihaly <diablo at best.com> wrote:
> 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.
I'll quietly note here that I have no formal CS education, and am in
fact self taught outside of some PET BASIC programming when I was
14/15. While I do have a pure maths background, I've never studied
or particularly learnt the math I refer to above. I'm merely aware
of it and some of its principles due to working with a number of
others who do have that sort of background and consider that
understanding an automatic assumption for the industry. (These are
the kind of people who are painfully smart)
This is why I caveat above that, "...(it) is still not really
necessary."
> 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*
A long long time ago I wrote a simple accounting system. It worked
pretty well on twin floppy systems (no HD) which were the state of
the art then. Performance comparitively sucked, and it had a nasty
tendency to eat data files. Why? Because on every operation, for
every single record I processed, I opened the relevent data file,
indexed to the record in question, read it, closed the file,
processed the record, and then repeated from the beginning for the
next record.
It was painful.
It also exposed instabilities and fundamental weaknesses in the PC
architecture.
It was also an almost perfect example of really stupid and bad
design and implementation.
The problem was that normally it worked, and despite the fact that
record IO routines were being called an obscenely large number of
times the OS was good enough that it never spent much time in those
IO routines so I never pgged them as the source of the problem...
> I just assumed that interpreted languages would be slower I guess
> becuase of the extra layer.
There is alsways an expense for bytecoded or interpreted languages.
However that expense need not be noticable or even really detectable
as long as the real throughput bottlenecks lay elsewhere.
> 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?
Yup. Its a "is this thing in a certain state, and if so, go do
that" check.
--
J C Lawrence Home: claw at kanga.nu
---------(*) Linux/IA64 - Work: claw at varesearch.com
... Beware of cromagnons wearing chewing gum and palm pilots ...
_______________________________________________
MUD-Dev maillist - MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list