Re: disabling GTK+ features to shrink GTK+
* Emmanuele Bassi eba...@gmail.com schrieb: because loading tons of small libraries is actually going to cost much more in terms of resources (memory, I/O, linking and loading time) Really ? did you measure it ? How often do typically gtk applications get startet - how many per second ? Most of the time is spent in loading the pages (disk io). Yes, this can be done lazy (requireing many, many page fault exceptions, so driving up CPU load), but that will only help us if the text segment is clustered along usage pattern (IOW: by smaller modules within the fat library), otherwise we've got huge chance that the whole text will have to be loaded even if we actually just use small portions. With separate smaller libraries, that's already inherent. Oh, btw, *If* you're really concerned about the dynamic linking overhead, wouldn't it be the right way to improve ldso in general, eg. by a kernel-based caching linker ? than loading a single library shared by many (if not all) applications. Well, on my system, only a few apps need gtk, and most of them only small portions. You souldn't do the mistake of building everything on unrealistic assumptions like gtk is only used in typical GNOME environments. (otherwise it someday *will only* be used there and and loose the all the rest of the userbase). for the past five years there has been an impressive effort in reducing the amount of small libraries scattered across the platforms - Yes, that's exactly why I've given up gtk+ development. I simply dont have the spare manpower to drive everything on my own, and if I had, I'd start afresh with different very concepts. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: How does gmainloop schedule GSources by priority?
Hi, On Sat, Aug 14, 2010 at 9:57 AM, cee1 fykc...@gmail.com wrote: I've written a test program, which creating watches for two GIOChannels: one for stdin with a low priority, and the other for a named pipe with a high priority. Then ran the program with no data written to the named pipe, it can still response to input of stdin, which seems like high priority sources will not block low priority sources. Priorities only matter if the sources are both ready. If only stdin has data and the higher priority one doesn't then the lower priority would run. prepare and check both return TRUE if the source is ready (should be dispatched, i.e. its callback should be invoked). the difference is that prepare is pre-poll and check is post-poll. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: disabling GTK+ features to shrink GTK+
On Sun, 2010-08-15 at 14:41 +0200, Enrico Weigelt wrote:
* Emmanuele Bassi eba...@gmail.com schrieb:
because loading tons of small libraries is actually going to cost
much more in terms of resources (memory, I/O, linking and loading time)
Really ? did you measure it ?
it's been measured multiple times, on multiple platforms - especially on
embedded ones.
How often do typically gtk applications get startet - how many
per second ?
that's absolutely inconsequential. *any* application linking to glib
and/or gtk+ would have that penalty - and the *fewer* applications (such
as your case) the worse it gets.
for better or worse, glib and gtk+ provide a platform (and ${DEITY}
knows how much I don't like that word); applications use the platform as
a whole or simply don't use it.
Oh, btw, *If* you're really concerned about the dynamic linking
overhead, wouldn't it be the right way to improve ldso in general,
eg. by a kernel-based caching linker ?
feel free to poke the kernel and linker people to do it, then.
than loading a single library shared by many (if not all) applications.
Well, on my system, only a few apps need gtk, and most of them only
small portions. You souldn't do the mistake of building everything
on unrealistic assumptions like gtk is only used in typical GNOME
environments.
oh, please. splitting up gtk and/or glib will yield the worst results on
small systems, and on systems that don't preload the whole stack - and
that even before hurting performance on a desktop GNOME installation.
after all, GNOME worked perfectly fine with dozens of little libraries
before. the performance gains in terms of environment start up time,
application start up time and memory usage have been documented and
verified.
for the past five years there has been an impressive effort in reducing
the amount of small libraries scattered across the platforms -
Yes, that's exactly why I've given up gtk+ development.
then why do you feel entitled to spend time whining about gtk+'s
development?
ciao,
Emmanuele.
--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: disabling GTK+ features to shrink GTK+
On 08/15/2010 06:41 AM, Enrico Weigelt wrote: because loading tons of small libraries is actually going to cost much more in terms of resources (memory, I/O, linking and loading time) Really ? did you measure it ? Can you prove that it doesn't? Until you can, there's no logical reason to change the way GTK+ is currently done based on your say-so. To blindly experiment on a massive scale as you propose is very expensive. Most GTK+ development is, of course, volunteer-based. And what has been done works well for many, many, people and companies, embedded or no. Well, on my system, only a few apps need gtk, and most of them only small portions. You souldn't do the mistake of building everything on unrealistic assumptions like gtk is only used in typical GNOME environments. (otherwise it someday *will only* be used there and and loose the all the rest of the userbase). Any change to GTK that slows GNOME down is likely going to be unacceptable, since that's where GTK+ is used the most. That said, GTK+ is being used quite nicely in a number of small, embedded environments. So is Qt, and Qt is at least as monolithic as GTK+. In any case I don't see GTK+'s size as being a problem in embedded development (yes I have done some embedded GTK+ developing in past years). for the past five years there has been an impressive effort in reducing the amount of small libraries scattered across the platforms - Yes, that's exactly why I've given up gtk+ development. I simply dont have the spare manpower to drive everything on my own, and if I had, I'd start afresh with different very concepts. Your comment does not logically follow. Reducing the dependency on various, small libraries makes it easier to drive everything on [your] own. Everything is streamlined. How does forcing you to examine numerous, dependent libraries and APIs make your life any easier? If you have given up on GTK+ development, why are you still talking about it here? There are lots of other options including Qt. Sorry to sound short, but I'm not buying into your arguments. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
