Zugg Software :: View topic

Posted: Wed Mar 29, 2006 4:12 am

The other good news that I have to report re: CMUD is that it has *much* better performance scaling.

In zMUD, the speed seems to scale with the "square" of the number of settings. For example, if you make a loop to create a bunch of random variables, here are the zMUD times:

Create 100 variables: 20 ms (roughly 10)
Create 1000 variables: 860 ms (roughly 1000)
Create 10000 variables: 96700 ms (roughly 100000)

so each factor of 10 in number of variables causes a speed factor of 100 (10^2)

I've done some testing and work on CMUD, and because of the database storage of settings CMUD has a linear performance curve. Here are the preliminary numbers for CMUD:

Create 100 variables: 78 ms (roughly 100)
Create 1000 variables: 844 ms (roughly 1000)
Create 10000 variables: 8625 ms (roughly 10000)

So as the number of variables increases by a factor of 10, the speed factor goes up by a factor of 10 also.

Currently the base number is larger in CMUD for small numbers (78 vs 20 ms in the above examples). Part of this is the overhead for changing a value in a database since it has to update the internal indexes. But don't worry much about this number because it's not optimized yet. What I mainly wanted to show is the linear scaling as opposed to the absolute speed values.

Btw, I purposely choose the worst possible case for zMUD. All of the variable names that are created all start with the same letter. In zMUD there is a separate "list" of names for each letter, but zMUD then does a linear search within the list. So when names are randomly scattered within the alphabet, it's a bit faster. But the fact that zMUD doesn't use any sort of index to speed up the lookups is responsible for the bad N^2 scaling.