# [SERVER] strings vs. code OR my MOO compiles fine and doesn't crash

ThwartedEfforts (abakun@scinc.com)
Tue, 11 Jun 1996 15:03:04 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    Because of some bookkeeping that we are trying to do on E_MOO, each line of
    verb code contains a list element as it's last line which stores certain values.
    Commonly, it's a list of the form:

    {some object, some number, some string, etc, etc}

    I can directly compare if it's more space efficient to store this as a list
    or a string using value_bytes, but a hard coded list, when it appears in
    verb code, is constructed by the VM on the fly from a number of opcodes (as
    shown by disassemble()).  (ignore the fact that strings/comments in code are
    still values; that's not how I mean it in this context).

    As such, the only way to measure which is better to store this data item (as
    a comment in code or as VM opcodes) is to use object_bytes() on an object
    once when a verb contains toliteral()'ed strings and once with the actual
    value in the code.

    Store as value/opcodes:                  Store as string:

    #x:test                                  #x:test
    {123456789, #1, #1, #1};                 "{123456789, #1, #1, #1}";

    ;object_bytes(#x)                        ;object_bytes(#x)
    => 1076                                  => 1082

      Savings of 6 bytes when stored as value/opcodes over as a string.

       (as a side test:
         ;value_bytes({123456789, #1, #1, #1})
         => 48
         ;value_bytes("{123456789, #1, #1, #1}")
         => 32
          Savings of 16 bytes when stored as a string.
        )

    So, the question is, has anyone done any tests that show at what point it
    becomes more efficient to store values as strings rather than opcodes.  I'm
    hypothsizing that and other notes (read: strings == toliteral()'ed value):
    1) as lists become more nested, it's more efficient to store as strings in
       code rather than as value/opcode.
    2) it's always more efficient to store a string rather than a list in a
       variable or a property (or any other place that a type of Var would be
       accepted).  This begs the question, then, if Var types are used in the
       assembled opcodes for the more basic types (INT, FLOAT, STR, OBJ) and
       if so, why are lists constructed on the fly instead of being stored as a
       Var type if they contain all literals and no expressions (I probally know
       the answer to this one: it's easier to just assume nothing is a literal
       and that everything needs to be evaluated to get at it's value -- but
       now I'm making sense).
    3) Of course, everything is stored as flat text in the db file, so I'm
       talking in terms of in memory.

    Any comments?  Any tests that would prove this wrong one way or the other?

    Andy...
     (...working on my spelling)