gtk+ speed
I haven't programmed much with gtk+, so forgive a noob if this is a silly question. My first impression when I looked at the architecture (using GObject etc.) was that this must take quite a bit of processing cycles and memory. So my question is: is there any room for improvement by rethinking the architecture (using Vala for some of the things maybe?) with gtk+ 3.0 in the works this question bothers me a bit :) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ speed
2008/12/22 Eugene Gorodinsky e.gorodin...@gmail.com: question. My first impression when I looked at the architecture (using GObject etc.) was that this must take quite a bit of processing cycles and memory. So my question is: is there any room for improvement by rethinking the architecture (using Vala for some of the things maybe?) with gtk+ 3.0 in the works this question bothers me a bit :) This has been discussed in the past. My memory is that if you take a typical app and profile it, you find that for typical tasks (eg. the framerate when resizing a window) less than 10% of the runtime is spent in GObject machinery. Of course that's just from memory :-( I've probably got it wrong. Anyway, the point being, before considering architectural changes you need to perform experiments, make measurements, and try to predict the gains you might be able to achieve. At the moment, as far as I know, there is not much evidence that GObject is a significant factor in GUI speed and responsiveness. ( John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ speed
On Mon, 2008-12-22 at 13:12 +0200, Eugene Gorodinsky wrote: I haven't programmed much with gtk+, so forgive a noob if this is a silly question. My first impression when I looked at the architecture (using GObject etc.) was that this must take quite a bit of processing cycles and memory. So my question is: is there any room for improvement by rethinking the architecture (using Vala for some of the things maybe?) with gtk+ 3.0 in the works this question bothers me a bit :) Vala is a high level language which is translated to GObject and C, so you are proposing to rewrite GObject using GObject. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ speed
Vala is a high level language which is translated to GObject and C, so you are proposing to rewrite GObject using GObject. Vala can be modified, since it is open source and all. I'm not sure if that's feasible though, as I'm not familiar with it. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ speed
Am Montag, den 22.12.2008, 14:27 +0100 schrieb Olav Vitters: On Mon, Dec 22, 2008 at 03:10:13PM +0200, Eugene Gorodinsky wrote: Vala is a high level language which is translated to GObject and C, so you are proposing to rewrite GObject using GObject. Vala can be modified, since it is open source and all. I'm not sure if that's feasible though, as I'm not familiar with it. Vala uses gobject. If you suspect gobject is slow, changes in vala won't affect gtk+. I think he proposed to rewrite GTK+ on top of vala and then rewrite vala to be faster than GObject (by using its own stuff, etc). So the real issue would be that we think one can't provide the features of gobject with 50% of GObject's CPU usage. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ speed
On mån, 2008-12-22 at 13:12 +0200, Eugene Gorodinsky wrote: I haven't programmed much with gtk+, so forgive a noob if this is a silly question. My first impression when I looked at the architecture (using GObject etc.) was that this must take quite a bit of processing cycles and memory. So my question is: is there any room for improvement by rethinking the architecture (using Vala for some of the things maybe?) with gtk+ 3.0 in the works this question bothers me a bit :) Another noob here. That was my first impression too. I then thought of all the code I've written in C# and Python, which works pretty well - I think the GObject overhead should be pretty insignificant in comparison. I think I got this impression of GObject because it forces you to really see the overhead, when most other languages/libraries works harder to hide more. For instance, the code generated for a virtual function in C++ is as far as I understand (as I said, noob here) in principle the same as the code you have to manually write in GObject to do the same thing, it's just much more invisible. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ speed
On Mon, 2008-12-22 at 15:22 +0100, Robin Sonefors wrote: I think I got this impression of GObject because it forces you to really see the overhead, when most other languages/libraries works harder to hide more. For instance, the code generated for a virtual function in C++ is as far as I understand (as I said, noob here) in principle the same as the code you have to manually write in GObject to do the same thing, it's just much more invisible. Exactly. C++ can do slightly more optimisation because the OO, casting and so on are in the compiler instead of built at runtime, but the underlying mechanics are the same. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ speed
On Mon, Dec 22, 2008 at 02:44:40PM +, Ross Burton wrote: the code generated for a virtual function in C++ is as far as I understand (as I said, noob here) in principle the same as the code you have to manually write in GObject to do the same thing, it's just much more invisible. Exactly. C++ can do slightly more optimisation because the OO, casting and so on are in the compiler instead of built at runtime, but the underlying mechanics are the same. As you say, because type casts are dinamic, there's the overhead of calling g_type_check_instance_* which in languages like C++ is not needed because it's done at compilation time. I suspect that this overhead is negligible (I haven't made real tests, though). However, there is a performance problem with private attributes (if you use g_type_class_add_private()) that don't exist in other languages, as GObject's g_type_instance_get_private() can be noticeably slow. There are ways of overcoming this problem, fortunately. More info here: http://arbur.net/serendipity/archives/40-g_type_instance_get_private-performance-costs.html http://www.gnome.org/~federico/news-2006-01.html#24 -- Alberto García González http://people.igalia.com/berto/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ speed
Am Mon, 22 Dec 2008 16:44:55 +0100 schrieb Alberto Garcia agar...@igalia.com: On Mon, Dec 22, 2008 at 02:44:40PM +, Ross Burton wrote: the code generated for a virtual function in C++ is as far as I understand (as I said, noob here) in principle the same as the code you have to manually write in GObject to do the same thing, it's just much more invisible. Exactly. C++ can do slightly more optimisation because the OO, casting and so on are in the compiler instead of built at runtime, but the underlying mechanics are the same. As you say, because type casts are dinamic, there's the overhead of calling g_type_check_instance_* which in languages like C++ is not needed because it's done at compilation time. I suspect that this overhead is negligible (I haven't made real tests, though). To be fair, you should consider that C++ has other overheads, and is particularly hard to parse from the perspective of a compiler. And C++ is not even the only condidate for comparison, there is also for instance Objective C, which is actually a dynamic language with properties and messages (~signals). In that regard the benefit of a hypothetical rewrite of Gtk in Vala would be about avoiding human error and added type safety, rather than making the type system faster. Much of performance problems in Glib applications come from the way it is used, and not from GObject, which is why I like the idea of integrating GObject with the language/ Vala. Just my 2 pfennig, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ speed
Hi, On Mon, 2008-12-22 at 16:44 +0100, Alberto Garcia wrote: However, there is a performance problem with private attributes (if you use g_type_class_add_private()) that don't exist in other languages, as GObject's g_type_instance_get_private() can be noticeably slow. That can easily be optimized away by keeping an opaque pointer to the private struct in your public object struct. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ speed
On Mon, Dec 22, 2008 at 07:54:59PM +0100, Sven Neumann wrote: However, there is a performance problem with private attributes (if you use g_type_class_add_private()) that don't exist in other languages, as GObject's g_type_instance_get_private() can be noticeably slow. That can easily be optimized away by keeping an opaque pointer to the private struct in your public object struct. That is explained in the links I left right after the paragraph you quoted :) -- Alberto García González http://people.igalia.com/berto/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ speed
On Mon, Dec 22, 2008 at 05:30:32PM +0100, Christian Dywan wrote: As you say, because type casts are dinamic, there's the overhead of calling g_type_check_instance_* which in languages like C++ is not needed because it's done at compilation time. I suspect that this overhead is negligible (I haven't made real tests, though). To be fair, you should consider that C++ has other overheads, and is particularly hard to parse from the perspective of a compiler. Yeah, I didn't mean to compare both languages, only to point out the additional overheads that GObject might have compared to other object-oriented implementations. -- Alberto García González http://people.igalia.com/berto/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
