Re: gtkhtml
- From: Daniel Veillard <Daniel Veillard w3 org>
- To: Count Zero <countzero cyberdeck org>
- Cc: gnome-list gnome org
- Subject: Re: gtkhtml
- Date: Thu, 29 Jun 2000 15:26:59 +0200
On Thu, Jun 29, 2000 at 08:21:42AM -0500, Count Zero wrote:
> > Saying "not linking to gnome-libs makes it faster" is what most
> > western cultures have defined as bullshit.
>
> No, your statements would be considered bullshit, since they are not backed by
> facts. It is common knowledge that smaller programs initialize and load faster
> than large programs. The fewer dependancies you have, the faster your
> application will initialize. (and the smaller its memory footprint will be, and
> the easier to install it will be, etc)
>
> The above statements assume all else is equal ... ie: application A and
> application B are identical except for the number of libs they link to. App A
> links to 10 libs, App B links to 3 libs. App B is gonna load quicker. (and it
> seems, run quicker too)
Especially if removing 7 libraries decreased the functionnality.
This analyze works IMHO only if those given 7 libraries were not already
loaded. This may be the case if you run none of the other Gnome applications
making use of it.
In the case of an integrated setup like gnome where a lot of apps shared
the appropriately named *shared* libraries, then if your application use some
of those functionalities it should be faster to use shared libs than duplicate
code for those functionalities in your binary. If you remeoved nothing
useful (i.e. assuming no other app in your desktop will ever need an HTML
engine, it's embeddability or it's capacity to print) then yes you may win.
But I doubt this assumption really has its place in
So the whole point of the exercise is that you proved that by isolating
a shared library, removing it's component facilities and printing capabilities
you can get a shared lib which loads faster ... Sure ... Big question,
is how useful it is and would that scale ? One may debate that.
It's also perfectly possible to say that the editing capabilities of
gtkhtml (or mozilla if you want another example) will only be useful
to a fraction of the application, so let's remove it too ... What would be
the result ? Fragmentation of libraries, then more memory footprint for
the global set of functionalities for a user environment desktop, hence
probably lower performances. The tradeoff cannot be cleanly analized by
just instrumenting one application. If Linux was running only one program,
we probably wouldn't use shared libs (I have seen the time where shared libs
were added to linux, my machine had 4 megs of RAM at that time and we felt
instantly the difference).
The fact that it allows your program to load faster is accepted, will
it make your desktop faster, yes only if you don't reuse that shared lib
anywhere else. If there is reuse (and i assume there will a lot of apps
needing embedded HTML renderers - helper, evolution and nautilus looksi
obvious ones -) then this may not be a smart move.
Now the qestion of how functionalities should be splitted between gtk
and gnome shared libs seems a far more sensible debate. I don't feel
confident to argue on this by lack of knowledge of gtk/gnome internals.
> By the way, it is just this sort of attitude on behalf of Helix personel that
> caused this fork in the first place...
I think Federico can feel the right to debunk you, not because he's
an Helix employee, but due to his knowledge/hacking history/... Not
at all the same thing.
> Arrogance has no place in the open
> source community (in my opinion)
At least from an historical point of view I tend to think its false.
I have seen quite a few people being crushed by authorities in the
Free Software world ...
relax,
Daniel
--
Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes | Today's Bookmarks :
Tel : +33 476 615 257 | 655, avenue de l'Europe | Linux XML libxml WWW
Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | Gnome rpm2html rpmfind
http://www.w3.org/People/all#veillard%40w3.org | RPM badminton Kaffe
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]