Re: GObject extension propose (GContainer)
On Fri, 2006-06-16 at 04:28, Tim Janik wrote: > On Fri, 16 Jun 2006, Gustavo J. A. M. Carneiro wrote: > > > Qui, 2006-06-15 às 13:00 -0400, Tristan Van Berkom escreveu: > > >> All of that just to say... I cannot count the times I've thought to > >> myself that > >> GtkContainer should really just be GContainerIface, and implemented by > >> whatever interested objects that want to parent other objects... > > > > That's interesting, but I wonder what is the runtime penalty of > > interface lookup compared to normal class structure lookup? Is it > > really OK to use an interface for this, or is it better just to add a > > new virtual methods to the GObject class? > > the lookup penalties are negligible. > type node/class lookups and is_a checks are O(1); > interface class lookups and conforms_to checks are O(ld(N)), where > N is the number of interfaces a type node conforms to. Your assertion that the penalties are negligable is not really supported by your response, unless the constant is also known for both orders. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.10, the endgame
Hi Murray, On Fri, 2006-06-16 at 10:52 +0200, Murray Cumming wrote: > I'm also concerned about the recent files stuff. Do we now have > UIManager integration of that? No, and I am to blame because I had less time to spend on fixing this issue. Mostly, I've been stuck on how to implement an action for both the menu and toolbars using the same tag. In the meantime, a nice and clean way to integrate the GtkRecentChooserMenu inside a GtkUIManager is to subclass GtkAction into a custom action that automatically adds a recent chooser menu to the menu item it creates, and use a placeholder in the UI definition (most applications using EggRecentViewUIManager already have that placeholder present). A working example is available here: http://www.gnome.org/~ebassi/test-uimanager.c The action code itself is one hundred lines long and can easily be hidden inside an helper file; it's approximately how GtkRecentAction would be implemented, anyway. I hereby give permission to do whatever you want to do with it. I understand that it's sub-optimal, and hopefully this should really go away once there's an action inside GTK. Ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Imagine: what if points in Bugzilla had a significant effect?
On 6/15/06, Jason Spiro <[EMAIL PROTECTED]> wrote: > Imagine: what if points did something in Bugzilla, like, the more points > you have, the more votes you get? > > I think this would encourage people to file more bug reports, both good > bug reports and not-so-good ones. Would that be a net gain or a net loss > for GTK+? This isn't the right list for this email; bugzilla-devel or filed in bugzilla (against the bugzilla.gnome.org module) would be much better. Thanks, Elijah ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gslice allocator: general impresions.
On Thu, 15 Jun 2006, Michalis Giannakidis wrote: > Dear Glib team, > > I have recently used the glib-glice allocator in a very malloc intensive > application, and I would like to share a few observations I made, with you. > > The typical size I send to g_slice_alloc is 20 and 76 bytes (32 bit build). > The total memory consumed by my application has decreased - which is great! > However it `seems' to me, that this decrease in size is larger for the 64bit > build compared to the 32bit build. (I have modified gslice to align a chunk > to its own size so that I don't have unused memory between chunks eg: request > 20 and get 24...) you mean you've set P2ALIGNMENT to 1 * sizeof(void*) to get better granularity of the slices? have you left NATIVE_MALLOC_PADDING at 2*sizeof(void*) at least? (if not, memory fragmentation on some glibc systems and on all 64bit systems can become etxremely bad). > In my application now I use both g_slice_alloc and malloc.Testing the new > allocator in linux I came accross the following: > After using g_slice_alloc to alloc a great amount of data (eg 1500mb), each of > them being 20 or 76 bytes in size, subsequent calls to malloc(8*1024) or > similar sizes take much longer (the allocation does _not_ got to the swap). this is a magnitude of memory allocations where gslice hasn't been well tested. (my machine only has 1GB of memory for instance). while gslice should perform well even much beyond 1GB, i'd suspect that malloc()/memalign() don't, and thus could result in *some* GSlice slowdown as well. > Also if I chage the min_page_size from 128 to 4096, then the subsequent calls > to malloc(8*1024) or similar sizes take even longer. It takes for ever in the > 64 bit build! maybe due to your alignment tweaks. but maybe also because some malloc() buckets will have even longer lists that way. > Moreover, even with min_page_size set to 128, the calls to malloc take for > ever on a Linux 2.4.20 glibc-2.2.4(glibc up to 2.2.5 has a broken > posix_memalign so I fallback to memalign). broken in what way? > In all of the cases above, malloc responds much faster when the gslice > allocator is turned off. aparently some malloc implementations aren't too good at handling large numbers of page allocations. if modifying GSlice is an option for you, you could try to work around this at the expense of read-only allocation of the memory used by GSlice. to do that, you need to disable the HAVE_COMPLIANT_POSIX_MEMALIGN, HAVE_MEMALIGN and HAVE_VALLOC branches in allocator_memalign() and allocator_memfree() so the read-only malloc()-based fallback allocator is enabled. on 32bit systems, that'll by default allocate 16*4096=64k areas to allocate pages from. by doing: - const guint n_pages = 16; + const guint n_pages = 2560; you'll instead allocate 10MB areas, which should put far less stress on the system malloc() (that way, to fill 1GB, a maximum of 100 allocations are required). > I know I should be providing sample code and test programms here to back up > my observations. I also understand that I should provide execution times > instead of just stating that the calls to malloc take for ever. test programs would be great. allthough this kind of stress test can only be run and examined on a limited set of machines. e.g. the development machines i use have just 1GB and normally have only 30%-40% of free memory to spare for tests during runs like make check -C glib/test ;) > I would like to ask you, if there are any known issues in mixing gslice and > malloc calls in malloc intensive applications. > Any suggested readings would be most welcome. you've already seen the two papers cited in the big comment block at the start of gslice.c? it links to: http://citeseer.ist.psu.edu/bonwick94slab.html http://citeseer.ist.psu.edu/bonwick01magazines.html the first of which describes a kernel page allocator which isn't implemented by GSlice. we use memalign() instead, on the assumption that this is good enough for the vast majority of applications out there. if malloc is too stressed out by the aligned allocations gslice makes in your scenario, implementing this page allocator on top of mmap() and using that as a base allocator for gslice may be another option. > Regards > Michalis --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject extension propose (GContainer)
Alan M. Evans wrote: [...] >>the lookup penalties are negligible. >>type node/class lookups and is_a checks are O(1); >>interface class lookups and conforms_to checks are O(ld(N)), where >>N is the number of interfaces a type node conforms to. >> >> > >Your assertion that the penalties are negligable is not really supported >by your response, unless the constant is also known for both orders. > > From my swift glance at gtype.c, it seems that in the case of an interface, the implementing interface is searched on that class's list of implementing interfaces... so when classes implement hundreds of interfaces it might be a performance hit. I dont think we've yet reached the day that we have to ditch good design and avoid using interfaces because of performance woes, that would be sorry day indeed... (I also dont think GTK+ code will be the only OO code needing major refactoring in those areas too... if these interface lookups weren't negligable) Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkFileChooser/GnomeVFS backend still messing up authentication manager? (was: GTK+ 2.10, the endgame)
Am Donnerstag, den 15.06.2006, 09:56 -0400 schrieb Matthias Clasen: > I want to have GTK+ 2.10 ready at or immediately after GUADEC. > > I did not declare 2.9.3 api frozen in the release announcement, > because we were still holding the door open for Kris' work on > the new tooltips api. But he has run into some difficulties > with the implementation which will take some time to overcome, > so we have decided to punt this feature and try to get it > into 2.12 early. > > Therefore, I want to consider 2.9.3 api frozen, and take a > look at what still needs to happen before 2.10. Here are some > things I personally would like get worked on (not sure > how much time I can free to look into these myself): > > - I think the async filechooser conversion has caused some > regressions, I noticed that .hidden support seems broken > and autocompletion also behaved badly for me recently. > > - There is a number of FIXMEs and unimplemented bits in > the print code. > > - The print backends need a careful look wrt to memory leaks > and error reporting. > > Are there other important bugs or regressions that need > attention before 2.10 ? Some months ago I investigated an issue where the GtkFileChooser requested file info for all shortcuts and caused mass login requests for all bookmarked remote locations on startup that require login with the GnomeVFS backend. I think the issue was that the file chooser has no way of requesting file info, but signalling at the same time that failure due to unavailability of resources or access constraints isn't fatal, allowing the GnomeVFS backend to not request login data when it is invoked through gtkfilechooserdefault.c:shortcuts_reload_icons. In that case, we may want to fall back to a folder icon. >From reading the GTK+ HEAD source code, the shortcut code still doesn't seem to pass any special flags, so it still seems to be relevant. -- Christian Neumair <[EMAIL PROTECTED]> ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.10, the endgame
On 6/15/06, Matthias Clasen <[EMAIL PROTECTED]> wrote: > Therefore, I want to consider 2.9.3 api frozen, and take a Does this mean that http://developer.gnome.org/doc/API/2.0/gtk/ix07.html (and equivalents for gdk, pango, atk) is now a fully stable source for bindings which want to support new features of 2.10? -- Guillaume Cottenceau - http://zarb.org/~gc/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
