javascript performance

[jon....@gmail.com]

What sort of performance goals does jsmud have?

Some possible metrics are:
* maximum number of active users for a given system configuration.
* average latency for a typical system load. (nobody wants to wait 5-10
seconds for a command to execute)
* processor usage for a typical number of active users. (if you are
running your MUD on some shell account, you don't want to take more
than your fair share)

This would depend almost entirely on how fancy your .js files are, of
course. And seeing as jsmud ships with the simpliest possible .js
files, I suspect we won't know what the performance is for quite some
time. But it would be nice to have some defined goals.

[Sean Middleditch]

On Sat, 2005-09-03 at 01:02 +0000, jon....@gmail.com wrote:
> What sort of performance goals does jsmud have?

It's not intended to ever run large scale MUDs, if that's what you're
after. It'll probably be most useful for prototyping spiffy new ideas
or running smaller MUDs.

The SpiderMonkey JavaScript engine has been used in a few other games,
but not anything big, flashy, and high-performance that I know of. That
said, I would imagine SpiderMonkey to be a rather well-performing
JavaScript engine (I know of no benchmarks for this). Other languages
with very similar language designs to JavaScript and internal
implementations similiar in spirit to SpiderMonkey, such as Lua, have
been used in a number of AAA games, including those that run on older,
very low-performance and resource-strapped consoles like the PS1. Those
of course are different beasts than a MUD, but it does give one a little
hope that JavaScript isn't too much of a performance killer.

It's also always possible to implement in C any particularly sensitive
code. For example, if we find that a lot of people need dense arrays,
it might make sense to implement one in C and expose it to the
JavaScript array. I won't bother with that until someone shows me some
evidence that it's needed, however.

So far as defined goals... I really am not prepared to offer any. I
myself really don't know what SpiderMonkey can handle, and I do plan on
keeping the amount of C code to an absolute minimum if possible.

--
Sean Middleditch <elan...@awesomeplay.com>