[FFmpeg-devel] GSoC with FFMpeg waht a combination!

[Uoti Urpala]

On Tue, 2008-03-25 at 22:10 +0100, Michael Niedermayer wrote:
> On Tue, Mar 25, 2008 at 12:16:12AM +0200, Uoti Urpala wrote:
> > On Mon, 2008-03-24 at 22:47 +0100, Michael Niedermayer wrote:
> > > On Mon, Mar 24, 2008 at 11:18:00PM +0200, Uoti Urpala wrote:
> > > > That's a fucked up table... there are 32 KiB of pointers to strings and
> > > > 32 KiB of actual strings (I assume you meant Ki, not k)? Assuming 4-byte
> > > 
> > > I didnt mean kiddy byte no.
> > 
> > Well no OS I know reads data in 4000 byte blocks...
> 
> No, but some do read in 4kb blocks. Iam not using the SI system of prefixes
> but rather the standard binary 1024 based ones. Which i am sure is obvious to
> everyone.

It was pretty obvious that reading "4kb" literally would not make much
sense in this particular case, which is why I noted that I was assuming
you meant KiB. It's not so obvious in other contexts.

> > >  And gettext needs more than 7 byte to store a
> > > 2 byte index IIRC. Complain to them for the fucked up format ...
> > 
> > WTF does the gettext implementation have to do with it? That was about
> > the behavior of binary search, not the gettext implementation (which can
> > use hashes). Your hash version was not the gettext hash implementation
> > either.
> 
> This thread was about gettext vs. alternatives.

This branch started from your claim that binary search would
automatically be slow, and that's what I have been talking about.

>                                                 None of the alternatives
> discussed, would use a binary search. Also none of the gettext files i
> ve seen actually used a hashtable.

And gettext doesn't have to use a binary search either. I just checked
two randomly picked .mo files I had on my system and both did contain a
hash table.

> So the comparission here being "what gettext does in reality" vs. "what
> a proper written hash table based system would do".

Even if using a hash table was rare (though I doubt the files I checked
were really exceptional) how does that equate with "what gettext does in
reality"? Certainly you can use the hash table for FFmpeg translations
whatever most other gettext-using projects do. If files without a hash
table are common then I think that's a further indication that even
gettext's less than optimal version of binary search does not cause
performance problems in practice.

> Anyway, if you were not arguing about gettext as you indicate in your 
> "WTF does the gettext implementation have to do with it?"
> then i do not see what you are arguing about at all. After all this
> thread was about gettext being a bad choice. And you where trolling
> that gettext would be all so great.

As explained above, what I've talked about in this branch of the thread
was your claim that systems asymptotically slower than O(1), and binary
search in particular, would be slow in practice.

My last post about the practical side of using gettext for FFmpeg (from
performance standpoint, not evaluating functionality otherwise) was
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-March/044284.html
which you haven't replied to. In short: Yes, the time and space usage of
gettext are not optimal. No, I don't think that is much of a practical
problem. And even if someone wants an optimized implementation I see no
reason why that would have to be done before adding gettext support, as
using the gettext api from the FFmpeg side doesn't seem to preclude a
more efficient lookup implementation.