From: Dominik Riebeling <dominik.riebeling_at_gmail.com>
Date: Thu, 19 Mar 2009 18:38:07 +0100

On Thu, Mar 19, 2009 at 4:04 PM, Thomas Martitz
<thomas.martitz_at_fhtw-berlin.de> wrote:
> Now imagine this for every char in a string, and for every string in a file
> list (with some 100 files). It's three-times (or even more) more complexity
> than just.
> while (is_zero(a))
>   a = next;

This "natural sorting" is more complex than ASCII sorting anyway. And
what's the added complexity by simply going back by one to get the
last 0? That's only an added check, and everything else only if you
hit a digit.

if(is_digit(a)) {
    /* is_digit() had a hit */
    while(is_zero(a))
        a = next;
    /* if current one is not a digit anymore we've just skipped the
value 0 and need to take that back to not remove that value */
    if(!is_digit(a)) /* no need to check if there is a prev value --
we skipped at least one 0. If not we still have a digit. */
        a = prev;
}

> We're on embedded, and thus slow systems. Your would surely work well on a
> desktop app, but for mp3-players we need fast and small code. The gain has
> to justify the code, and I don't think it does it in this example.

We're talking about high-level functionality here. There's nothing
timing-critical, and even on the Archos players I'm confident doing
this properly wouldn't cause a serious slowdown compared to the
current state, but feel free to measure it and present numbers. We can
play mp3 files at <45MHz (at least on coldfire, don't have all the
numbers at hand right now) which is much more calculating-intensive
than doing a few additional comparisons on a list of maybe some 100
files.

You're basically saying we shouldn't fix the functionality because
it's too expensive runtime-wise. If it's really too expensive to have
a functionality working properly (which I doubt) we shouldn't ship the
functionality at all.


 - Dominik
Received on 2009-03-19