[Coco] the final stage of optimization

[Aaron Wolfe]

"File Structures: A Conceptual Toolkit" by Micheal Folk is the best
book I've ever read on these topics.  If you are interested in the
subject, I think you'll find helpful.   It is very detailed but also
easy to read even without prior knowledge of the subjects, a rare
combination in computer science books.

This is the version I have:

http://www.amazon.com/File-Structures-Conceptual-Michael-Folk/dp/0201120038/ref=tmm_hrd_title_0

Look like you can get a used copy for a couple bucks, well worth it
IHMO.  There is also an updated version that gets good reviews, link
from the same page.

-Aaron


On 11/20/09, Wayne Campbell <asa.rand at yahoo.com> wrote:
> It would be nice to keep the data in ram. I have been toying with the idea of trying to use GFX2's buffer commands to see if I can use them to store the records in memory and work on them there. Then I would only need to create the file when it was ready to be saved. I'm really uneducated in terms of things like indexing and linked-lists and the like. If you wouldn't mind, could you explain the index with keys and record positions idea? It sounds interesting.
>
> Wayne
>
>
>
>
> ________________________________
> From: Aaron Wolfe <aawolfe at gmail.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Fri, November 20, 2009 8:46:09 AM
> Subject: Re: [Coco] the final stage of optimization
>
> Hi, I don't know your project well enough to be sure, but this seems
> like a situation where keeping the data in ram, or at least an index
> with the keys and record positions, would be worth the space.  Have
> you considered something like that?
>
> -Aaron
>
>
> On Fri, Nov 20, 2009 at 2:33 AM, Wayne Campbell <asa.rand at yahoo.com> wrote:
> > I have been aware that the one thing that is slowing decode down more than anything else is having to use disk files to store, search and sort records. This email concerns searches and sorts.
> >
> > I have never really gotten a good understanding of how search and sort algorithms are designed, and how they operate, beyond the least complex. When I wrote DCom, I wrote sort procedures that were recursive. They worked, but I never really understood if they were working efficiently or not. I do know that the sorting operations were faster after they were modified.
> >
> > In decode, I am using a simple search algorithm. Basically, it starts with the first record, and continues reading each succeeding record until either a match is found or the last record is read. The number of records that get added to the file depends on the I-Code being decoded. The more records in the file, the longer the search takes.
> >
> > Three files are created, variables reference, line reference, and literal reference. Decoding createmsg (one of Ron's modules, about 2K in size), the decode takes about 20 minutes. Decoding RConfig (another of Ron's modules, about 16K in size) takes about 40 minutes. Decoding decode (20K) takes 2 hours.
> >
> > I have the same problem with my sort. I'm using a sifter-style (for lack of a better term) of sort. It starts with the first record, proceeds to the last record, then performs the sort in reverse, starting with the last record and proceeding to the first. Each pass of the routine performs both of these operations. It works, and it was much faster than using the top-to-bottom method I first used that was based on the search routine. However, it takes as long to sort the literals records as it does to decode the instruction section of the I-Code module.
> >
> > There has to be a better way. Can someone help me understand how to make my search and sort algorithms faster?
> >
> > Wayne
> >
> >
> >
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
> >
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>