Meeting on irc.gnome.org:#gtk-devel Meeting started November 9 2004 17:05 EST (22:05 UTC) In attendence: Owen Taylor (owen), Jonathan Blandford (jrb), Manish Singh (yosh), Matthias Clasen (matthias), Sven Neumann (neo), Michael Natterer (mitch) Tor Lillqvist (tml), Robert Ögren (roboros) sorry for being late ok, do we have any agenda items ? over an hour late, actually, the invitation said 21:00 UTC... I am mostly interested in figuring out our progress wrt to finalizing the api tml: hmm, did I mess up ? was there some clock shift in Europe ? isn't it now 22:08 UTC? daylight saving time ended last weekend here ah, that would be it. sorry, hopefully we can work out a more acceptable time for next week. We should probably discuss any issues of your interest first (not that it matters, i would have been awake anyway, and having this at a fixd *local* time makes it easier to remember... ;-) so, of the 15 items left on Glib 2.6 API freeze, are there any which we should work on before 2.6, or are we fine with declaring the current api final for 2.6 ? are did the desktop-entry parser get finished? seems to not be the case. then I will move the remaining items to 2.8 api freeze after the next release (which I plan to do around the end of this week) jrb: finished in what sense ? matthias: API finalized jrb: halfline incorporated most of markmc's comments, so I think it is in good shape but I will check with halfline tomorrow - or you could try to look around if he's still in the office okay tml: are the filename encoding changes complete, api-wise ? matthias: would think so, yes matthias: need to change gtk to use them, presumably? tml: yes. Did you adapt all internal glib uses to the new api ? (I remember adding a couple of filename_to_utf8() calls for error messages earlier during 2.6...) I did the ones I came across. didn't really do a systematic search I will look for the ones i added... those error messages presumably now should use g_filename_get_display_name yes...there is one non-api glib bug which I would like to discuss today the one about performance of signals with many handlers. neo, do you have the bug number at hand ? 153727 it severely affects heavy users of uimanager, such as gimp 2.2 looking at the numbers that mitch has collected, it affects all gtk+ apps but in gimp-2.2 it's a real showstopper what other "big signals" do other gtk apps use to be affected by it ? (I still think we need to redo UI manager not to make that many signal connections) (if you are going to have thousands of ientical connections, GSignal is neither space efficient nor time efficient) agreed. I can look into that this week do you think we should hold off on the gsignal optimization until that is done ? that optimization is certainly not wrong I agree that gtkuimanager shouldn't do that many signal connections matthias: What's the memory ovrehead for the additional pointers? but it isn't uncommon to have a considerable number of signal connections on some central objects owen: it is two pointers per HandlerList, and I think we have one HandlerList per object with signal connections neo: I'd be somewhat more comfortable about this thing if you guys had tracked down why things were performing so much worse in the gimp than in the synthetic benchmark neo: That would give me more confidence that we understood what we are optimizing owen: we did that opening a new image in gimp 2.2 goes down significantly if I use the patched glib the profiling shows that we also need to look at the smart separators neo: "why" because in gimp there is an average of about 25 signal connections per object, and the patch speeds up any of these g_signal_connect() mitch: Is that median or mean? while connecting these signals, it iterated hundreds of millions handler structs mean but each iteration is the same penalty so average or mean doesn't matter here mitch:So, it's 100's of objects with 2-3 conncetions, and one GtkSettings? no, gtksettings is a great part mitch: No, it does, because it's n^2 in the number of signal handlers on the object ... that's the proble but the curve is not that steep there are lots of objects with many signal connections in gimp not in gtk well, also in gtk probably. but definitely in gimp I will try to come up with some numbers for that The basic equestion I have is that your benchmark shows it takes 0.34 seconds to add 10,000 signal handlers to one object Then in the gimp, you are claiming that your patch is making huge amounts of difference to the particular operation of creating menus when you have ~7000 items. i have a patch with numbers, just it doesn't apply any more working on it Now, of course, 0.34 seconds is still a while, but that discrepancy just doesn't make me happy. mitch: if you can attach an updated measuring patch to the bug, that would be nice In terms of memory usage, each Handler is currently 6 words, and a HandlerList is 2 words, so 2=>4 words for HandlerList is probably fine. Now, actually, we could use the head->prev = tail, tail->next = NULL trick to save one of those words if we didn't mind a little extra complexity good idea do we have further input on that bug ? otherwise I would like to switch to gtk to see where we stand wrt to api freeze there matthias: Not from me, basically I think it's OK. n^2 algorithms are worth attacking. I have done a number of small api additions over the past week, but I wonder if you think that any of the ~130 bugs on GTK+ 2.6 api freeze are must-have, or if we can just continue to make small additions until end of november, then declare the beginning-of-december version api frozen... the one api addition I want to look at specifically are colin gdk-pixbuf thread-safety and selinux patches <-> module api, though ok, final question before I have to leave for dinner with the kids: did you have time to look at the state of PangoRenderer, owen ? matthias: No, I didn't. Which, I guess means that I have to back it out, according to what I said last week thats what you said, but of course, you have the option to quickly fix it up instead... matthias: I'll do one or the other :-) owen: i did expect no less from you :) ok, I have to leave now. As I said, I want to start looking into uimanager performance tomorrow, and I expect to do 2.5.5 release around the end of the week. Bye Meeting ended November 9, 17:51 EST (22:51 UTC)