From: Paul Louden <paulthenerd_at_gmail.com>
Date: Wed, 29 Oct 2008 23:18:37 -0500

Roy Wallace wrote:
>
> I agree, but I think the goal of this thread is to clarify for some
> people exactly how important binary size is, by coming to a
> compromise, a consensus, so as to avoid having the same argument
> repeatedly on a case by case basis.
>
Since the original message in this wasn't explicitly, or solely, about
binsize, I don't think this is the point at all.
> One way to reach this compromise is with a formal set of guidelines,
> which take into account the figures and the situation, e.g. the 2.3 MB
> RAM target that Paul points out. I personally do not know enough to
> draft these guidelines, but I'm sure many of you are. Is it possible
> to quantify the effects of binsize?
Not really, since it varies on target-to-target basis. For example,
binsize is exceedingly important on any target where we could
potentially run out of RAM entirely. Binsize bears almost no value at
all on 64MB targets where we could probably grow the core binary to 4MB
and see only a barely measurable loss in battery life.

But it has to be discussed on a case-by-case basis, for the very reason
that not every feature uses binsize well. For example, a two features
may each use 5k of binsize. One helps a small group of users, but is
actually necessary for that small group of users to be able to use
Rockbox effectively at all. The other one makes life very slightly
better for all users. Clearly each one should be discussed independently
as their value, and why they are valuable, is debatable despite their
equal binsize costs.

There is no objective way to value "how much it helps those it helps"
and we have no metric to by which to determine "how many it will help"
so we can only go on our own opinions of the value of the feature, to us
and our own guesses as to the user base.

Even if we set a 2.3MB maximum, that wouldn't allow us to say "okay, no
debating features as long as someone wants them, until we reach the
cap." Instead we'd be saying "Look, when we reach 2.3MB used RAM, we
can't add any more features at all without removing features. What we
need to do, now, is look at this feature and say 'do we think it's
likely we'd be willing to remove it in the future?' and if the answer to
that is yes, we may as well just go ahead and scratch it now, because we
should strive to get features that really increase the overall value of
the software, rather than 'filler' features that allow it to do more,
but we're readily willing to cut later."
Received on 2008-10-30