1. Edom 2.02
- Posted by Arthur Adamson <euclid at ISOC.NET> Jun 21, 1998
- 613 views
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
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Jun 22, 1998
- 597 views
> 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
- Posted by Arthur Adamson <euclid at ISOC.NET> Jun 22, 1998
- 602 views
>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
- Posted by Robert Craig <rds at EMAIL.MSN.COM> Jun 22, 1998
- 599 views
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