[MPlayer-dev-eng] [RFD] Something...

[D Richard Felker III]

On Sun, Apr 13, 2003 at 09:04:08AM +0200, Gábor Lénárt wrote:
> On Sat, Apr 12, 2003 at 04:37:58PM -0400, D Richard Felker III wrote:
> > On Sat, Apr 12, 2003 at 09:30:45PM +0200, Gábor Lénárt wrote:
> > > On Fri, Apr 11, 2003 at 09:17:19PM -0400, D Richard Felker III wrote:
> > > > > uses glib2, but probably doesn't depend on gtk. Using something like
> > > > > glib2 is probably better than hacking up your own method.
> > > > 
> > > > glib is disgusting too, and glib2 even moreso. In helping with irssi
> > > > support on irc over the past year or so, one of the top things users
> > > > have been annoyed about is the glib dependence.
> > > 
> > > But this is exactly the key problem of today's Linux system. Almost EVERYONE
> > > writes own code for the SAME thing which should be in shared libraries only
> > > once. OK, case of windows is even worse (there is no choice in many cases),
> > > but the redundant code in each softwares means slower startup (just see
> > > complex programs like openoffice of mozilla) and memory wasting ...
> > 
> > This is total nonsense. Bloated shared libs make for MUCH slower
> > startup than writing simple minimal implementations of this stuff as
> 
> Hmm, I didn't write about situations where a huge lib is used just for
> one or two functions which can be implemented in few dozens of byte of

But that's what most people use it for! :))

> code in your program :) But about a year ago I finished a little project
> where I calculated memory usage by a tipical GUI ;) Linux user. So eg if he

I couldn't care less how much memory a "typical gui linux user" uses.
These people are the same people who'll go spend $3000 on a junky Dell
P4 with 768 megs of ram, so it's irrelevant. I care how it performs on
a $200 computer.

> use gnome, glib is used by several running processes it's much cheaper to
> use glib for a newly launched process. Of course not if you're using KDE
> instead. And so on. OK, it's hard to messure these facts in GENERAL but only
> for a well defined situation.

My well defined situation is no X, no gui crap, just plain simple
movie player from command line.

> > it's needed. The problem is brain damaged "object oriented"
> > programming. Yes it will be slow if you make a generic full-featured
> 
> OO is really brain damaged I also think that :)

Glad we agree on this. :)

> > linked list 'object' in your program, and do the same for string,
> > resizable array, hash table, etc. etc. etc. -- BUT it will also be
> > slow if you use glib[2] to do the same thing!! Instead you should
> > write just what you need. In most cases, you only need a pointer
> > (struct whatever *next) and a few lines of code to manage a linked
> > list, not a few megs of glib crap!
> 
> It's NOT that simple. For most cases maybe you're right. But not always.
> First of all, optimizing for memory usage and optimizing for speed are somewhat
> different things and cannot be done easily for these two goals at the same
> time!

Agreed. I just think glib optimizes for neither. Rather, glib
optimizes for helping newbie programmers simplify their jobs at the
expense of memory usage *and* performance for the user.

> I'm not talking about a certain situation but only in general that you shouldn't
> refer al libraries as unusable ones. If you do, implement libc as well in
> your program. Sure, it will be somehat faster :)

Not really -- very few (performance-intensive) programs use libc
significantly anyway.

> > > So probably using glib or glib2 is a GOOD idea because if multiple programs
> > > using them, they will have shared library memory usage (at least at the side of
> > > code size in memory, because code segment is shared).
> > 
> > >From what I understand, this also makes code slower because it has to
> > use PIC! If you want performance, your shared libraries will be built
> > without PIC, and then they use additional memory for each different
> > binary running that's linked to them.
> 
> Yes, on x86 architecture this can take even 10% of performance, because x86
> platform has too few regiters and we must use one for storing GOT to
> calculate from global offset table. But it also true that it depends on
> the usage! So if the example situation code is NOT time ctritical it could be
> nice. HOWEVER, eg in case of mplayer core, implementing a codec in shared
> object may result in heavy performance loss ... Or just read documentation
> of mysql, it says thet performance can be tuned up by static linking about
> libraries.

Well making it a shared object is ok as long as you don't use -fPIC.
But without PIC, the memory saving benefit is negated, and the only
point of using a shared object is for dynamic loading.

> So in a nutshell, I didn't want to write that you should use should use glib
> just for using a few functions within a time critical loop, I only wanted to
> write that you should be carefull to analyze the situation for a given
> example.

I just don't see glib as being very meritful to begin with....

Rich