[MUD-Dev] memory and speed

[Chris Gray]

[Matthew Mihaly:]

> We tripled our memory today, from 128 megs to 384 megs, but we seem to
> actually have slowed down. In fact, adding more memory has definitely
> slowed us down. Some tasks are taking nearly twice as long as before. This
> is extremely upsetting, to say the least. Anyone have any ideas?

[I've just finished going through 50 MUD-Dev messages - I'm going to put
all my performance comments here.]

Does your server code know about the extra RAM? i.e. are there parameters
you give it telling it how much it can use? If so, it may have some
code in it that increases its run-time in proportion to the amount of
stuff it has to work with. If not, then it sounds like something similar
is happening in the operating system. Is it Linux, Windows, commercial UNIX?

The normal reason to add RAM to a machine is to reduce the paging. I.e.
you are using more space than the real RAM, so the machine has to save
some of it to disk, then bring it back when its next needed - that's slow.
Adding more RAM helps there be enough space to not need to send things
to disk. If you aren't paging, its unlikely that more RAM will help.
How can you tell? On Unixes and Windows NT there are tools to tell you.
Task Manager on Windows, vmstat on many Unixes, including Linux.

Another possibility is disk I/O. Does your server have to read/write to
an on-disk database frequently? Mine does, but with good caching, it
isn't a problem. vmstat can tell you how much disk I/O you are doing.
When you machine is bagged, and you put your head beside it, can you
hear the disk continuously chittering away? If so, I'd suggest that
either paging (unlikely given the result with more RAM) or disk I/O
is costing you bigtime.

Matt, it sounds like most of your server's actual work is being done
by code written in the in-MUD language. While I agree that such an
interpreted language need not be a real bottleneck, I think that it
*can* be a bottleneck. The overhead imposed by such a language will
depend on a lot of things, such as:

    - amount of type checking and conversion needed at run-time
    - amount of C-code support functions available to be called
    - availability of lower-level facilities for special cases
    - the "level" of the language itself

Without knowing more details, its hard to say much more. Here are some
of the aspects of, and things I've done to, my interpreter to make it
faster:

    - its strongly typed. Therefore very little checking is needed at
	run-time, and no non-explicit conversions.

    - I have a *lot* of builtin-functions (coded in C) that the
	interpreted code can call on. Thus, even though my entire
	scenario is written in the MUD language, when it runs, it
	actually spends a lot of its time in C code.

    - I identified some things that I was doing that looked expensive,
	and wrote builtin-functions to do them (as generically as was
	reasonable).

    - I've added a byte-code compiler and machine to my system. So far
	it hasn't helped the X86 version as much as it did the 68K
	version, but I have more ideas to implement.

All of these issues can, I believe, account for a minimum of an order
of magnitude in the speed of the interpreted code. Possibly as high or
higher than 2 orders of magnitude. If nearly all of the action in your
MUD is being done by an interpreter at the slow end of that scale, then
that itself could be enough to cause your problems.

--
Don't design inefficiency in - it'll happen in the implementation.

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA
               http://www.GraySage.Edmonton.AB.CA/cg/


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