1. RE: Euphoria 2.5 Features..... ??
Mario Steele wrote:
> *bonks himself*
>
> Okay, maybe not 100k, but instead of 73k, more like 54k, or
> smaller. You have to think about how much of that, is reading
> routines, and interpreting said code, into objective code, then
> actual execution. Especially in defining keywords, instead of
> their counterpart tokenized objective code. :P If that makes any
> sense.
I'm looking at the size of the .obj files from my modified interpreter,
compiled by OpenWatcom 1.0. The scanner makes up about 23% of the sum
of the sizes of all .obj files (where said sum is just slightly less
than the size of the .exe). The scanner itself is only 8% (I'm not
entirely clear on what y Let's assume that you can eliminate all 8%.
After UPX, I get a file that's 44% the size of the original executable
(mine is 76k vs the official 72k).
Supposing that these things all remain constant, I would expect to have
a 'binding executable' of about 70k--8%, or about 6k smaller than the
original. DOS would be different, since we don't use UPX, and the
executable is bigger anyways (I think because of the graphics and
Causeway), but Linux would probably be very close.
My personal opinion is that you probably don't gain much in size
relative to the problems this will create. Rob will basically have to
write a separate translator to translate into Eu objective code, or
whatever, plus be able to use it, and then fix all the weird bugs, which
will be difficult to track down, given the already cryptic error
messages you get from bound or shrouded files. Also, I suspect that
programs that people will consider worthy of binding are going to be
considerably larger than the overhead of the interpreter (pick your
favorite GUI libarary), let alone this potential 6k (or even the entire
76k!) reduction in size.
Matt Lewis
2. RE: Euphoria 2.5 Features..... ??
> From: Al Getz [mailto:Xaxo at aol.com]
>
> Hello there Igor,
>
> First off, that algorithm probably doesnt work for sequences
> that dont have lengths that are multiples of 4. It's a neat
> idea though 
>
> Second, why would you want to go through all that trouble
> when you can use allocate_text()/free() pairs to manage
> the storage of text if you are THAT worried about the
> waste of memory due to character sequence storage ?
Meditor uses a similar scheme to store text. However, it packs 3
chars/element to avoid creating doubles. You just need to make sure that
you pad the sequence as necessary.
It undoubtedly is a lot less trouble than direct memory storage, since
Euphoria handles all the garbage collection, reallocation, etc., especially
for an editor-like application.
Matt Lewis
