[MPlayer-dev-eng] New translation system

[Rich Felker]

On Thu, Nov 30, 2006 at 06:04:01PM +0200, Uoti Urpala wrote:
> 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.

No, I advocate excellence in all areas. gettext is SHIT IN ALL AREAS.
Performance is the least of my concerns here.

> A translation system based on the English strings *is* a good performing
> design;

I won't even honor such crap as this with a response...

> 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.

Asm is microoptimization. Having the correct big-O is not
microoptimization. Any implementation with suboptimal big-O is plain
idiotic.

> > 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).

They'll thrash the cache. MPlayer does NOT need any more cache
thrashing than it already has.

> > 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.

This is the hideous GNU method: Use all sorts of horrible complex data
structures to "buy back" performance after you threw it out the window
with fundamentally idiotic design!

Rich