1. Edom 2.02
Ralf, I have finally tried EDOM 2.02 in my tree work. The results are
Number of words in the tree : 13000
Number of characters in the words : 72078
Number of bytes in a standard sequence holding the input words: 600136
Number of bytes in my tree holding the input words: 153252
Disk bytes used for tree saved via print(...) to disk : 248318
Disk bytes used for tree saved via edo_save(...) to disk : 128473
Disk-save time for print(...) : 0.56 Sec
Disk-save time for edo_save(...) : 403.33 Sec
Disk-read time for -----get(...) : 3.03 Sec
Disk-read time for edo_save(...) : .65 Sec
Summary: EDOM is remarkably fast and efficient except for save time.
I hope you can fix the non-linear save time, which varies approximately as
the square of the size of the object saved. It is perhaps caused by the
recursion used in EDOM?
Bye, Art
Arthur P. Adamson, The Engine Man, euclid at isoc.net
2. Re: Edom 2.02
> Ralf, I have finally tried EDOM 2.02 in my tree work. The results
are
> Summary: EDOM is remarkably fast and efficient except for save
time.
>I hope you can fix the non-linear save time, which varies approximately as
>the square of the size of the object saved. It is perhaps caused by the
>recursion used in EDOM?
To be honest, its still a mystery to me. I'm in the dark here. There's only
one guess
I would suppose it is due to the fact I have all the data in *one* sequence
at the end.
This sequence grows dynamically. In your case usually with 4-elements
(bytewise reprensentation of a machine integer).
I suppose Euphoria simply gets a lot slower handling a long sequence.
As I guess, Euphoria doesn't even know how to append. (sorry)
It approximated the length of the new sequence. It allocates room for it. It
writes out the origininal sequence. It writes out the 4 elements that are
being added. It dealocates the original sequence. It sets the pointer to the
new sequence. Robert, am I right ?
And as to recursion, that is being handled. The data-sequence is a local
sequence, so we don't have to be afraid that we are gonna push 72,000
elements on a stack. (well, I assume Euphoria will push the pointer on the
stack and allocate a new one, anyway). So it couldn't be recursion, I
suppose its the sequence length.
Well, its good to know this before I release EDOM3. I've already been
working on it. EDOM2 wasn't user-friendly enough, to add your own
compression routines. EDOM3 will make a difference between a device header
(simulate a I/O device: good for packing, resource binding, networking), and
a transformation before and after. An transformation before, will be
executed before the sequence is flatted (good for sequence optimizations &
modifications, I'll include a few). A transformation after, will be executed
after the sequence is flatted. (good for compression algorithms, encoding,
encrypting, etc.)
It will be backwards compatible with edom2.02 and with EDOM1. (EDOM2.01 is
incompatible as to 32-bit machine integers, all other types will work and
EDOM2.00 didn't work at all 
Ralf
nieuwen at xs4all.nl
3. Re: Edom 2.02
>Disk-read time for -----get(...) : 3.03 Sec
>Disk-read time for edo_load(...) : .65 Sec
>
>
Sorry for the error, change edo_save to edo_load. Thanks Andy for
catching it. Bye, Art
Arthur P. Adamson, The Engine Man, euclid at isoc.net
4. Re: Edom 2.02
Ralf writes:
> As I guess, Euphoria doesn't even know how to append.
> (sorry) It approximated the length of the new sequence. It
> allocates room for it. It writes out the origininal sequence.
> It writes out the 4 elements that are being added. It dealocates
> the original sequence. It sets the pointer to the new sequence.
> Robert, am I right ?
In the worst case, that's what it has to do.
(I haven't looked at your code lately).
Statements like:
x = append(x, value)
are very efficient. So are:
x = x & s
where s is much smaller than x (1/8 the size or something).
In these optimized cases, Euphoria can usually just
"grow" the sequence without having to allocate new space
or copy the original x.
In other cases (as David Cuny discovered a long time ago)
Euphoria will revert back to the "dumb" method of allocating
space for a new (larger) sequence, copying into it and freeing
the space for the original sequence (if there are no more
references to it).
Statements like:
x[i] = append(x[i], value)
and
x[i] = x[i] & s
are not optimized.
I suggest running a time profile when edom is processing
a large amount of data. Let us know where the time
is being spent. (try to minimize any time that it spends
waiting for user input, so you get more accurate results.)
Regards,
Rob Craig
Rapid Deployment Software
