[Tinymux] What is FIRANMUX + MEMORY_BASED

[Stephen Dennis]

On 5/22/06, Michael Wenk <wenk at praxis.homedns.org> wrote:
> On Monday 22 May 2006 09:07 am, Stephen Dennis wrote:
> >    - LBUF_SIZE is doubled from 8000 to 16000.
>
> I am curious, but what does this help/hurt?  16k large buffers seem like a
> possible waste of space on attributes, etc.

On the object, an attribute is only given as much space as it needs --
not the full LBUF_SIZE. The same goes for @mail bodies. The
slowly-changing buffers are therefore smaller than 16000 bytes.

Command, Function, and lock evaluations as well as global registers
use and release buffers so quickly that it's OK. That extra space is
used and reused very quickly. Only a few buffers linger from that
activity.

So, the working set is only a tad larger to support the possibility of
16000 bytes buffers. If you have a need for that much space, it would
be necessarily coded to be split across two attributes anyway.

There are two other reasons for avoiding 16000 that make some sense or did:

The first is that a CHashPage must be at least 3 times the size of the
largest possible attribute for technical reasons related to the data
structure. A CHashPage is the minimum transaction size to the disk.
Changing even a small attribute causes the entire CHashPage to be
treated as dirty, and a larger CHashPage is more work for the hard
disk. It's not that big a deal, but the effect is measurable.  With
MEMORY_BASED, that issue is side-stepped.

The second is that 16000 is twice as much room for crafting expensive
softcode. With limits on the CPU and with the other limits, the
expensive softcode problem isn't as much of a threat as it once was.


Brazil