[DGD] another aspect of persistence

[bart at wotf.org]

On Tue, 30 Sep 2008 10:01:57 -0700, Shentino wrote
> Speaking of ticks...
> 
> Burning tons of ticks to seek out and update all your clones may
> actually be more expensive than keeping everything centralized and
> updated only once.

This is true, but even when you fix the 'longdesc issue', there are lots of
other potential issues, such as variables that need conversion, that will
cause you to have to find and call upgraded on all those clones anyway. You
need a system that can do this, if it is to be used each and every time is
another matter. Also, following a linked list from the first to the last node
(which is how clone 'finding' seems to be implemented on most DGD libs) is not
that expensive unless you have a lot of clones.

You'd have to run a lot of upgrades to make up for ticks spent each time a
desc is queried. 

On top of this, a recompile/upgrade is something you somewhat prepare for,
then run with i/o blocked, and then it is finished. It is incidental, and that
it will for the time of the upgrade stop the mud is maybe not entirely nice,
but a lot less problematic then causing lag during normal playing time.

Hence, the impact of ticks spent during an upgrade is much less then ticks
spent during normal operation, and unless you have a design in which clones
never contain any local state that may need conversion, you can't really
escape the need of calling an upgrade function in every clone.

Bart.
--
Created with Open WebMail at http://www.bartsplace.net/
Read my weblog at http://soapbox.bartsplace.net/