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

[D Richard Felker III]

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
it's needed. The problem is brain damaged "object oriented"
programming. Yes it will be slow if you make a generic full-featured
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!

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

Rich