Rockbox mail archiveSubject: Re: Playlist Handling Alg
Re: Playlist Handling Alg
From: Lion Templin <ltemplin_at_leonine.com>
Date: Mon, 3 Jun 2002 05:17:06 -0500 (CDT)
On Mon, 3 Jun 2002, Daniel Stenberg wrote:
> 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.
Don't underestimate what users will do. :) There may be a case where
someone has thousands of tiny files, or some else that would result in a
large number of individual files. Know well that if there are limits
somewhere in software, users will find them and attempt to violate them.
The more robust and capable you make code, the less you have to kludge it
later when someone needs to go beyond what you've written.
And I know that there will be people that get 40G or larger drives. I
bought mine for many reasons, and one was it's potential extended lifetime
through the use of larger drives.
> It would make the song list easily addressable and it would give us a
> "perfect" random.
Considering the limits on memory and cpu the device imposes upon us, the
benifits of a O(n/2) alg to shuffle seem to outweigh the ideal of a
"perfect" random. The ADT I have described allows for fast acceptable
randomization with several other good side effects, like it's scaleability.
Of course, what I propose is a somewhat ideal case. The code is not
terribly difficult, though it is slightly more complex than a simple array.
My assertation (from years of experiance) is that it's better to take the
effort to implement a more robust alg now, then it is to rewrite it later.
= lion is Lion J Templin (KB9ENE) lion_at_leonine.com =
= || // ||> UNIX Systems Consulting for the =
= ||=EONINE \OMPUTATIONAL ||\ESOURCES Northland FROM the Northland =
= UNIX Systems Consultants http://www.leonine.com =
Received on 2002-06-03