[MPlayer-dev-eng] New translation system

[Uoti Urpala]

On Thu, 2006-11-30 at 16:13 +0100, Attila Kinali wrote:
> You should strive to use a good performing design whenever
> you do something.

Yes - but not without understanding what is a "good performing design",
which doesn't equal neglecting everything but performance. What Rich
advocates seems to be a system where all design decisions are based on
performance considerations only, even when performance is irrelevant and
there are other much more important factors.

A translation system based on the English strings *is* a good performing
design; it's not anywhere near a bottleneck. That you can make another
system which runs even faster (but in this case works worse and does
less) doesn't mean that the first system didn't perform well. Choosing a
"faster" translation system because of performance reasons is like
writing custom asm for parsing commandline arguments; it just doesn't
have any real benefits.

> Indices have to be fast to look up. Which means it has to be
> some form of integer. If you use a string, you'd need to do
> hundreds of strcmp's.

With a trivial binary search implementation you'd need to do about a
dozen. Though doing even hundreds likely wouldn't have a noticeable
performance impact (not that many strings are printed).

> Of course, you can use a hash over the index string, but then you
> only hide the fact that you are using an integer as index.

If you want really fast you can cache results for constant format
strings by hash based on the memory address of the string. Though I
somewhat doubt doing such optimizations would be worth it; even the
simplest methods would likely be fast enough.