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

[Daniel Egger]

Am Sam, 2003-04-12 um 22.37 schrieb D Richard Felker III:

> This is total nonsense. Bloated shared libs make for MUCH slower
> startup than writing simple minimal implementations of this stuff as
> it's needed.

This point is only valid for bloated shared libs which glib certainly
isn't. Also having many eayeballs on some piece of code ensures a
minumum of bugs while rewriting everything from scratch does not.

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

You don't understand how glib works because it doesn't operate with
"linked list 'object'"s. It simply defines strongly typed datastructure
which defines exactly the same attributes your your generic one would
have, i.e. for a single linked list:

typedef struct _GSList          GSList;
 
struct _GSList
{
  gpointer data;
  GSList *next;
};

No bloat in here.

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

You still don't have a clue. Don't you get tired of exposing yourself as
moron?

> >From what I understand, this also makes code slower because it has to
> use PIC!

Minimally. But it gains performance because the code in question is more
likely to be "hot in cache".

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

You can also link glib statically if you really prefer.

-- 
Servus,
       Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20030413/e82c49cb/attachment.pgp>