[Coco] the final stage of optimization

[Wayne Campbell]

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