RFC: Adding zlib dependency to libgio

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

RE: RFC: Adding zlib dependency to libgio

sbaka


LOL...

amen man.. NO MFC please!!!!!



i'm EMAILING FOR THE GREATER GOOD
Join me


> Date: Mon, 9 Nov 2009 23:03:14 -0500
> Subject: Re: RFC: Adding zlib dependency to libgio
> From: [hidden email]
> To: [hidden email]
> CC: [hidden email]; [hidden email]
>
> On Mon, Nov 9, 2009 at 6:23 AM, Alexander Larsson <[hidden email]> wrote:
>
> > I know you're really interested in cross-desktop VFS support, and I
> > don't disagree with having something like that. However, the fact is
> > that libGIO is an important part of the Gtk development stack, that
> > contains all the stuff that developers that want to write Gtk+ apps
> > want.
>
> i've written some relatively big GTK apps. i've never wanted to use
> any of the facilities that GIO offers me. how is it central to GTK?
> maybe to GNOME apps? i don't know - I don't target GNOME at all.
>
> > Just like Qt contains all that Qt developers want/need.
>
> This was one of the primary reasons I chose GTK over Qt. I'll make my
> own choices about libraries for IPC, sockets, UUIDs and the like,
> thank you very much. I was looking for a widget-based GUI toolkit, not
> MFC ....
> _______________________________________________
> gtk-devel-list mailing list
> [hidden email]
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

nf2.email
In reply to this post by Matthias Clasen-2
On Tue, Nov 10, 2009 at 1:41 PM, Matthias Clasen
<[hidden email]> wrote:

> On Tue, Nov 10, 2009 at 5:49 AM, nf2 <[hidden email]> wrote:
>> On Tue, Nov 10, 2009 at 9:44 AM, Alexander Larsson <[hidden email]> wrote:
>>> On Mon, 2009-11-09 at 23:03 -0500, Paul Davis wrote:
>>>> On Mon, Nov 9, 2009 at 6:23 AM, Alexander Larsson <[hidden email]> wrote:
>
>>
>> As I'm reading the word Gtk+ here more often: I still believe that a
>> VFS API shoudn't be tied to a certain UI toolkit. That would be
>> repeating the mistake KIO did. What about Mozilla, OpenOffice, VLC and
>> many many others. They should all link GIO (as a VFS API). If libgio
>> dupulicates too many things they already have, they might be put off.
>
> Whether GIO contains DBus support or not has probably minimal
> influence on whether or not Mozilla or OpenOffice use it. They make
> their own decisions about what platform to build on and don't care if
> you think they 'should' use anything in particular.
>

The modularity of the GLib stack is a nice feature. A lot of things
which are built with it, might be very useful far outside Gtk+ and
Gnome.

Let's take for instance libsoup: It already links GIO. But for what
sake would a HTTP client library always need to carry D-Bus around?

On my system, Gtk+ links 44 libraries. I guess one less or more won't
make any difference. Or, for instance a "gvfs-ls /" , which probably
has to load about 15 libraries, takes 0.03 seconds. Therfore - I
reckon - gathering unrelated APIs into a single *.so won't have any
significant performance benefit. But maybe i'm wrong.

Norbert
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

Thiago Macieira
Em Quarta-feira 11. Novembro 2009, às 03.54.53, nf2 escreveu:
> On my system, Gtk+ links 44 libraries. I guess one less or more won't
> make any difference. Or, for instance a "gvfs-ls /" , which probably
> has to load about 15 libraries, takes 0.03 seconds. Therfore - I
> reckon - gathering unrelated APIs into a single *.so won't have any
> significant performance benefit. But maybe i'm wrong.

Actually, it does.

There's a performance penalty in loading each library, plus a combined penalty
of symbol resolution. Remember that each library has a different symbol
resolution search order, so the dynamic linker needs to keep the map for each
library. And the more libraries you have, the more libraries you have to walk
through with failed resolutions before you reach the library that provides the
symbol you're searching for.

Moreover, inter-library symbol dependency requires expensive relocations. When
it's inside the same library, a cheaper absolute relocation is possible. This
affects more C++ code (the vtables) than C code (which would go through lazy-
binding PLT), but still affects enough to be relevant.

There used to be some tools to measure the ELF hashing performance, as well as
the average number of lookups to reach the conclusion of undefined symbol. I'm
sure Ulrich Drepper's DSO Howto paper has some more information.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

signature.asc (197 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

Alexander Larsson
On Wed, 2009-11-11 at 09:33 +0100, Thiago Macieira wrote:

> Actually, it does.
>
> There's a performance penalty in loading each library, plus a combined penalty
> of symbol resolution. Remember that each library has a different symbol
> resolution search order, so the dynamic linker needs to keep the map for each
> library. And the more libraries you have, the more libraries you have to walk
> through with failed resolutions before you reach the library that provides the
> symbol you're searching for.
>
> Moreover, inter-library symbol dependency requires expensive relocations. When
> it's inside the same library, a cheaper absolute relocation is possible. This
> affects more C++ code (the vtables) than C code (which would go through lazy-
> binding PLT), but still affects enough to be relevant.

This is exactly why we're adding stuff to libgio.so rather than adding a
new library for every new feature.

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Adding zlib dependency to libgio

nf2.email
In reply to this post by Thiago Macieira
On Mon, Nov 9, 2009 at 4:05 PM, Thiago Macieira <[hidden email]> wrote:
>
> As for your argument on "living on the same apartment", I disagree a bit. I
> think we're still at the "same building" stage, where we share our piping,
> heating, electricity, we cooperate in the building council, but we haven't yet
> moved into the same unit.

I'm afraid you are condemned to live in the same unit. At least if you
want more applications to move in. :-)

>
> Another way to see it is from the "Innovator's Solution" book. The author
> expresses a theory in which companies and entities go through cycles of
> interdependency and modularity. I think that applies to us: we're still in the
> state of interdependency, where the product is "not good enough" yet and we
> need a high level of flexibility and the ability to make non-standard
> interfaces, in order to stay competitive.
>

KDE and GNOME are definitely acting like companies, there are a lot of
competitive feelings involved. The problem is, that you are not only
trying to build different cars, but also your own roads. This won't
turn out well.

"[...] uncoordinated markets driven by parties working in their own
self interest are unable to provide these goods in desired
quantities." (http://en.wikipedia.org/wiki/Public_good)

Norbert
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
12