From: Daniel Stenberg <daniel_at_haxx.se>
Date: Mon, 3 Jun 2002 11:46:43 +0200 (MET DST)

On Mon, 3 Jun 2002, Lion Templin wrote:

> It is unreasonable to store the contents of the playlist in memory as a
> structure containing the list's filenames. This makes the amount of memory
> unpredictable and possibly consuming. Therefore, a simple and
> space-deterministic method should be used. In this case, we simply store
> byte-offsets into the playlist where each entry begins. Optionally, we can
> also store the length of each entry for easier reading by lseek(), without
> requiring a second parse & imposing a file length limit. Obviously, we
> will build this index of integers by scanning the playlist at initial load
> time.

I don't think we need to store the file name length, simply since it offers
very little gain.

> To store these integers, a useful ADT must be considered. Arrays are not
> useful becuase we want to build our list at load time, and we will not know
> the total length. Predefined arrays limit the number of entries in our
> lists. We cal realloc(), but that will cause fragmentation and loss of
> available memory.

[ Currently Rockbox runs with 128Kb of heap memory available for malloc() but
in fact nothing in the 1.0 release is using malloc(), everything is using
static memory! ]

Now, I think we should use arrays for this list. Sure, realloc() might cause
fragmentations, but if very large chunks is used the effect would be very
little. I mean, if increasing the size in like 4 or 8 Kb steps.

According to me calculations, if we assume that there are "weirdos" with 40GB
hard drives, they will still almost never have even 10000 songs. So, a static
memory area to support this amount of songs would need merely 40000 bytes. I
think that since we would still need to design the memory sizes for the worst
case, we can use the worst case always. imho.

It would make the song list easily addressable and it would give us a
"perfect" random.

-- 
  Daniel Stenberg -- Rocking the box => http://bjorn.haxx.se/rockbox/

Received on 2002-06-03