MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

LPMOO and binary db sillyness

You know, I had a couple laughs at the reasons why binary db's are 
bigger, had a few REAL LARGE ones in fact...

Eventually, I assumed somebody would give the -real- reason, but I guess 
everybody who's clueful enough to know thought the same thing, so I drew 
the lucky straw....

------ PAY ATTENTION:

LPMOO binary databases are so significantly higher then the standard MOO 
database for two -PRIMARY- reasons, there are others:

  1) The LPMOO has to store original MOO source code -and- the 
     LPC translated equivalent. Remember folks, LPMOO is not a native 
     interpreter like MOO, it compiles it to the native LPC language and 
     then interpretes -that-, it needs to keep the original MOO source 
     around so you can edit it, list it.. etc..

  2) There is overhead in LPMOO itself. Again, LPMOO is not `native', 
     there is significant overhead in the database to provide the 
     functionality of the conversion from MOO to DGD itself. All MOO 
     builtins have to be reimplemented

----------

Ok, for some reason I assumed this was all in the LPMOO docs, so I was 
getting huffy cuz people weren't looking, but I wasn't able to find it 
myself, still, some of the answers were outright incredibly wrong.

Oh, and (on an ASCII based system) an A is saved as decimal 65 regardless 
of if it is saved in a text file or a binary database. In fact, that's 
kind of a silly distinction as the OS couldn't care less. `Text' files 
are just binary files using only a subset of characters, with \n 
(newlines) spread usefully thruout the document.


Marc                                       http://www.got.net/marc
marc@got.net                               Finger for PGP key and Geek Code
Home | Subject Index | Thread Index