At 06:02 PM 07/23/99 +0200, you wrote:
>>> I had a quite small Compass-program, though very often saved and
>>> changed.
>>> The size of it was about 65000 bytes. I already though this was absurd
>>> but
>>> since it .ASM-files are a direct dump of Compass memory I guessed a lot
>>> of additional information had to be saved.
>>
>> when you do a lot of 'cut 'n pasting', there are many empty gaps
>> generated in the textbuffers. That's why it takes up so much space.
>> It's the fastest method though.
>
>Hmmm... I don't care that much about speed when cutting and pasting.
I do. WBASS2 could get quite slow when cutting and pasting with a large
source. And that was just 20K, imagine the same slowdown on a 100K source...
>If it
>takes a little more time but the source keeps 10 times as small then I don't
>care a damn. I bet it will speed up assembling too.
It might make a small difference in assembling speed: depending on how it's
implemented the number of slot switches could decrease. But I don't think
it would be spectacular.
Anyway, a factor of 10 as reported by Laurens is a lot.
Isn't there some kind of theorem that states you can always limit the ratio
of "space consumed" / "actual data stored" to 2 ?
Does Compass ever re-use freed space? Or join adjecent free blocks to form
larger free blocks?
You could make Compass compact sources in the background while the editor
is running. It may be tricky to program, but I think there is CPU power
unused while editing.
You'll probably re-write the source storage of Compass anyway, since when
using tokenized lines, a pointer per line would take more space than the
average line contents.
I once had to reverse-engineer the source storage of Compass. I was writing
a JoyNet send or receive program and Compass crashed. I was so concentrated
on the debugging that I forgot to save for a long time.
Compass was running under MSX4PC, so I was able to dump the MSX memory to
file. Fortunately the source was still there. I wrote a little program to
extract it into an ASCII file.
>I believe that. But I don't like to do this. Maybe you can include an option
>in some menu 'optimize source code' or so???
It could be done automatically. For example, before assembling Compass
could calculate the amount of slack space, and compact if it's more than
16K. But I still prefer the background compacting idea...
Bye,
Maarten
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****
