From: Robert Tweed <robert_at_killingmoon.com>
Date: Mon, 12 Aug 2002 19:51:21 +0100

----- Original Message -----
From: "John Wood" <John.Wood_at_royalblue.com>


> >> To do that, you need a temporary storing space for those, let's say,
500
> names. And then we would have gained nothing, since we need to allocate
> space for that temporary storage. <<
>
> Yeah but it's temporary. You can free it once you're done sorting. It
won't
> interfere with anything... it'll just come and go in the blink of an
eye...
> :)

Unless the memory is already allocated for buffering that MP3 playing in the
background! :) You could always use a multi-pass sorting algorithm, and
simply keep the allocation at 200, but it would cause a lot of
disk-thrashing and lower the battery life somewhat. Still, I suppose it
would be a good alternative to a hard-coded ceiling on directory size, in
the unusual case where a directory > 200 entries is encountered for whatever
reason. Especially since it wouldn't adversely affect directories < 200
entries.

Alternatively, perhaps it would be possible to change the memory allocation
at runtime? If the player encounters a directory > 200, it deallocates some
MP3 buffer memory. Would that screw up the rest of the code really badly
though? Still, we have to ask what would happen if the directory is greater
than the physical memory in the box. The line has to be drawn somewhere,
unless a progressive algorithm is introduced at some stage.

All in all though, I regard this as more of an academic issue than a
practical one. The way my files are organised means I don't generally have
more than about 30 files/subdirectories in any given directory. Still, it
would be nice to remove the physical memory limit altogether, just for the
overall robustness of it.

- Robert
Received on 2002-08-12