**** BEGIN LOGGING AT Mon Feb 21 14:36:01 2005 Feb 21 14:36:01 --> You are now talking on #gtk-devel Feb 21 14:48:42 --> jrb (~jrb@cpe-66-189-91-28.ma.charter.com) has joined #gtk-devel Feb 21 14:54:18 --> alejandro (~alejandro@78.Red-80-35-162.pooles.rima-tde.net) has joined #gtk-devel Feb 21 14:55:49 --> j_ali (~ali@host-84-9-26-232.bulldogdsl.com) has joined #gtk-devel Feb 21 14:59:36 --> bkor (~bkor@d206067.upc-d.chello.nl) has joined #gtk-devel Feb 21 15:03:22 --> djcb (~djcb@b212-54-27-205.elisa-laajakaista.fi) has joined #gtk-devel Feb 21 15:14:18 --> tim (~tim@dsl-217-155-195-89.zen.co.uk) has joined #gtk-devel Feb 21 15:17:50 --> diego (~diego@80.26.160.232) has joined #gtk-devel Feb 21 15:50:48 --> jpe (~jpe@pool-151-203-108-239.bos.east.verizon.net) has joined #gtk-devel Feb 21 15:51:26 --> pbor (~paolo@host182-185.pool80180.interbusiness.it) has joined #gtk-devel Feb 21 16:00:56 --> halfline (~rstrode@dsl092-077-227.bos1.dsl.speakeasy.net) has joined #gtk-devel Feb 21 16:02:18 yosh? Feb 21 16:04:07 --> fatalerror (~fatalerro@c906374f.virtua.com.br) has joined #gtk-devel Feb 21 16:04:52 --> andersca (~andersca@luminoth.csbnet.se) has joined #gtk-devel Feb 21 16:06:26 --> lgs (~lgs@200-206-134-238.async.com.br) has joined #gtk-devel Feb 21 16:06:30 --> Tester (tester@Ottawa-HSE-ppp4038875.sympatico.ca) has joined #gtk-devel Feb 21 16:06:34 <-- Tester (tester@Ottawa-HSE-ppp4038875.sympatico.ca) has left #gtk-devel Feb 21 16:09:10 --> mitch (~mitch@p5488C506.dip0.t-ipconnect.de) has joined #gtk-devel Feb 21 16:09:11 --> Chipzz (chipzz@lea.ulyssis.student.kuleuven.be) has joined #gtk-devel Feb 21 16:09:13 --> fer (~fherrera@246.Red-81-36-74.pooles.rima-tde.net) has joined #gtk-devel Feb 21 16:09:16 --> markdrago (~mdrago@ool-18ba8444.dyn.optonline.net) has joined #gtk-devel Feb 21 16:09:49 --> dindinx (~dindinx@ALyon-209-1-20-48.w81-50.abo.wanadoo.fr) has joined #gtk-devel Feb 21 16:10:26 --> owen_ (~otaylor@209-6-188-30.c3-0.wth-ubr2.sbo-wth.ma.cable.rcn.com) has joined #gtk-devel Feb 21 16:10:48 okay, let's begin Feb 21 16:11:09 ben maurer has been doing some measurements on how much memory the toolkit uses Feb 21 16:11:15 hey Feb 21 16:11:24 "toolkit" is gtk, pango, glib, gobject, fontconfig, freetype, etc. Feb 21 16:11:27 so, first, i started making a page about desktop wide stuff on the wiki Feb 21 16:11:34 http://live.gnome.org/MemoryReduction?action=show Feb 21 16:11:47 that was what i wrote up in the last 20 minutes, so its not polished at all ;-) Feb 21 16:11:48 since those are used in all the apps, anything allocated by the toolkit adds up for the whole desktop's memory consumption Feb 21 16:12:11 --> marc (~marc@usr1302-gh1.blueyonder.co.uk) has joined #gtk-devel Feb 21 16:12:17 yeah, so, the first thing to look at for gtk+ memory usage is a hello world Feb 21 16:12:33 BenM: "Using GTK+ from HEAD on Feb. 21, 2005, a simple Hello World took over 4.5 MB of RSS" - how about using something more meaningful than RSS? Feb 21 16:12:40 <-- halfline has quit (User disconnected) Feb 21 16:12:44 yeah, lemme give malloc stats Feb 21 16:12:56 ==7284== still reachable: 457933 bytes in 6262 blocks. Feb 21 16:12:57 4.8 Meg RSS is pretty meaningless since it doesn't say how much is shared Feb 21 16:13:00 thats from valgrind Feb 21 16:13:10 --> jdub (~jdub@home.waugh.id.au) has joined #gtk-devel Feb 21 16:13:42 BenM: That's better.... you miss the shm segments that way, but it is closer to a realistic number Feb 21 16:13:58 yeah, well thats going to get messy to measure Feb 21 16:14:04 --> seb128 (~seb128@ANancy-151-1-14-133.w83-194.abo.wanadoo.fr) has joined #gtk-devel Feb 21 16:14:11 i'd pay for a tool that gives good numbers :-) Feb 21 16:14:31 anyways, there is alot of stuff going on at very low levels here Feb 21 16:14:46 for example, there are quite a few small malloc's from the type system Feb 21 16:14:48 --> rahga (~rahga@66.196.18.76) has joined #gtk-devel Feb 21 16:14:55 like, g_memdup'ing 4 bytes Feb 21 16:15:08 I think a mempool impl could help out Feb 21 16:15:13 BenM: the gnome system manager should give you a better view of mapped segments, or you can parse /proc/maps yourself Feb 21 16:15:23 how much shm do we use these days? Feb 21 16:15:33 BenM: Why not gather some stats to help? memprof will tell you the total number of mallocs Feb 21 16:15:44 i've got those stats too Feb 21 16:15:48 (using memusage) Feb 21 16:15:50 federico: A *lot* - I think it's 480kb / process on a 32-bpp system Feb 21 16:16:02 BenM: Total number of live mallocs? Feb 21 16:16:11 thats not live, the live one comes from valgrind Feb 21 16:16:29 Oh, you have the 6262 blocks above Feb 21 16:16:34 yeah Feb 21 16:16:44 its interesting how much temporary allocation is going on Feb 21 16:16:46 so, you know that the *maximum* that a mempool could save you is 24k :-) Feb 21 16:17:12 If all allocations were constant size and could be put into a single mempool Feb 21 16:17:23 mempool doesn't need constant size Feb 21 16:17:34 (i was thinking of a chunk of memory that gets pointer bumping0 Feb 21 16:17:35 BenM: If you want to save per-block overhead Feb 21 16:17:41 BenM: You mean GStrChunk? Feb 21 16:17:49 something like that, but for non-strings Feb 21 16:18:02 wasn't that gnu obstacks? Feb 21 16:18:09 obstacks would probably work Feb 21 16:18:11 maybe the real problem is that glibc never ever returns mem blocks below 4k to the system? Feb 21 16:18:30 --> kov (~kov@201.135.184.24) has joined #gtk-devel Feb 21 16:18:35 BenM: I suppose you could use block allocation for never-freed structures in the type system Feb 21 16:18:35 mitch, yeah, not returning could be part of the problem Feb 21 16:18:41 is there a tool that lets you see which blocks live on which pages? Feb 21 16:18:43 owen_, exactly Feb 21 16:18:47 federico, i wish Feb 21 16:18:57 i would love to see something like that Feb 21 16:19:11 But I really haven't seen the evidence yet that the culprit here is partial block allocation Feb 21 16:19:35 I think fontconfig and the shm segments are pretty dominating (and fontconfig does a *lot* of allocations itself) Feb 21 16:19:42 yes, it does Feb 21 16:20:04 i count aobut 150 kb on my hello world Feb 21 16:20:11 thats out of the 500 kb of mallocs from valgrind Feb 21 16:20:21 for shm, i think the major problem is string relocations Feb 21 16:20:26 like the enum bug i filed last night Feb 21 16:20:34 I'm talking about X shm segmetns Feb 21 16:20:37 no, this is shm segments from gdkrgb Feb 21 16:20:37 ah Feb 21 16:20:41 ok Feb 21 16:21:01 Stuff like panel applets really shouldn't be allocating the RGB segments Feb 21 16:21:26 well, panel applets seem bloated having their own process anyways :-) Feb 21 16:21:32 so, other than show-me-blocks-per-pages, is there a way to monitor heap fragmentation? how many temporary little blocks get used/freed for a typical signal emission? Feb 21 16:21:40 e.g. would it make sense to do Feb 21 16:21:44 i can get a meg or two back by killing the clock Feb 21 16:21:45 push_new_mempool() Feb 21 16:21:47 signal_emit() Feb 21 16:21:51 pop_mempool() Feb 21 16:21:52 federico, possibly Feb 21 16:22:07 we might as well alloca Feb 21 16:22:08 federico: The result I've heard is that fragmentation tends to bound. Feb 21 16:22:13 --> scristian (~cristi@pc117.vimaro-ge.suceava.rdsnet.ro) has joined #gtk-devel Feb 21 16:22:24 well, there were quite a few small allocations on startup Feb 21 16:22:37 * BenM searches for #s Feb 21 16:22:48 Histogram for block sizes: Feb 21 16:22:48 0-15 10775 19% ========================= Feb 21 16:22:48 16-31 21332 37% ================================================== Feb 21 16:22:48 32-47 4146 7% ========= Feb 21 16:22:51 BenM: alloca's make code pretty much unreadable when done right, because you can seldom *just* alloca .. you have to guard for large sizes Feb 21 16:23:22 yeah, probably a few hotspots need to be found Feb 21 16:23:23 owen_: bound how? Feb 21 16:24:10 owen: would it make sense to delay initializing shm segments until the app tries to blit an image larger than NxN? Feb 21 16:24:10 BenM: You should be able to get fragmentation waste statistics easiyl enough by comparing memprof/valgrind statistics to /proc/maps Feb 21 16:24:20 (so that small-sized applets go through the socket) Feb 21 16:24:39 owen_, well, that doesnt count brk calls, does it? Feb 21 16:25:29 federico: E.g., the total allocated memory from a good allocator after a long run is only maybe 1.5x the live blocks ... should be ever better with the 4k mmap'ed segments in glibc Feb 21 16:25:35 BenM: you can see that in there too Feb 21 16:26:22 ah, ok Feb 21 16:26:49 owen_: right Feb 21 16:26:58 so, in terms of the mallocd memory, once you take out fontconfig/freetype, it is pretty much down to the type system Feb 21 16:28:04 I think basically what needs to be done is get a classification of where the allocations on startup are coming from before we start talking about mempools or whatever. Feb 21 16:28:19 yeah Feb 21 16:28:31 using mempools would, ironically, be one of the easiest ways of doing that Feb 21 16:28:31 owen: you know that freetype (or fontconfig?) stuff with tagged mallocs? Feb 21 16:28:42 f_malloc (12345, "this_comes_from_glyph_data") Feb 21 16:28:48 and then you can print out stats Feb 21 16:29:10 (Personally, my guess is that if you want to make the desktop usable on small memory systems, evolution/firefox is a lot more of an important target than GTK+ ... GTK+ per process overhead is at least bounded) Feb 21 16:29:24 federico: You've seen memprof in actuion, right? Feb 21 16:29:49 owen_: yeah, grouping by stack trace is fantastic Feb 21 16:29:50 Or for something less likely to be broken, massif? Feb 21 16:29:57 owen_: I wonder if it picks up everything that you want to know, though Feb 21 16:31:19 federico: it should be pretty close, right? Feb 21 16:31:39 And doesn't require code modiifcation or recompilation, which is a big plus Feb 21 16:31:42 federico, memprof and massif should both catch everything Feb 21 16:32:28 btw, one nice tool is mozilla's leaky Feb 21 16:32:40 <-- fer has quit (Ping timeout: 600 seconds) Feb 21 16:32:41 it is basically a malloc logger Feb 21 16:33:24 that could be useful for looking at the temporary allocs Feb 21 16:33:24 --> loz (~loz@195.60.29.140) has joined #gtk-devel Feb 21 16:33:52 BenM: What's our target here? Speed or memory? Feb 21 16:34:15 well, overall the only thing the user cares about is speed Feb 21 16:34:16 Temporary allocations don't matter for memory. And only matter for speed if malloc shows up in profiles :-) Feb 21 16:35:24 BenM: Not exactly. They care about how much $ they have to spend for RAM to get a certain speed level Feb 21 16:35:54 or unupgradeable obsolete laptops Feb 21 16:36:07 low-end hardware, basically (really big in the third world) Feb 21 16:36:45 Making GNOME pleasant on 256M of memory would benefit quite a few people even in the US. (its' probably not that bad with smaller sets of mail folders than I have) Feb 21 16:37:29 absolutely Feb 21 16:37:56 And certainly we get customer requests for running in 128M though I think that's a little unrealistic to be pleasant no matter what we do Feb 21 16:38:19 pagemaker kicked ass on my 4 MB 386 Feb 21 16:39:02 is there an easy way to make the kernel pretend you only have X mb of ram Feb 21 16:39:13 we should tell developers how to experience a low end box Feb 21 16:39:21 linux mem=256M or something, right? Feb 21 16:39:23 You used to be able to boot it with mem= I think] Feb 21 16:39:39 can somebody get instructions and put them up on the wiki Feb 21 16:39:57 I think tools are a lot more useful that that. Feb 21 16:40:12 owen_: still, if fragmentation is bounded over time, do we need nice tools to draw heap diagrams? Feb 21 16:40:24 Most GNOME developers have a pretty good idea what their box would do if you booted it with mem=128M Feb 21 16:40:37 I mean, they look very cool on SGI tools, but I've never actually used them to profile stuff Feb 21 16:40:54 federico: I don't think time based memory profiles have much value, really Feb 21 16:41:38 federico: What would be useful for tools beyond what memprof/massif gives you is some better stats on *actual* memory usage across the desktop Feb 21 16:42:32 for some definition of actual... Feb 21 16:43:03 BenM: for a definition of actual that somewhat approximates the real question of "how much memory do I need" Feb 21 16:43:54 BenM: that takes into account mapped executable pages and sharing of such, shm segments, memory usage in the X server (xrestop info say), so forth Feb 21 16:44:52 yeah Feb 21 16:45:07 So, along with measurement tools, you want one or two "reference desktop configurations" (what panel applets, what app, which documents) that can be used as baselines Feb 21 16:45:32 absolutely Feb 21 16:45:43 some sort of reproducable number Feb 21 16:46:17 so, crazy idea: Feb 21 16:46:22 1. the screensaver kicks in Feb 21 16:46:44 2. a gui-less memprof engine goes through each process, saving all their heap profiles Feb 21 16:46:59 3. they get accumulated somewhere that hackers can see the profiles Feb 21 16:47:07 would that be useful? Feb 21 16:47:14 yes Feb 21 16:47:23 [I'm reminded of the fedora boot time thing] Feb 21 16:47:30 federico: memprof unfortunately needs to be there from the beginning, and has a pretty high overhead. Less detailed stats could still be useful though Feb 21 16:47:33 something like the fedora boot time thing Feb 21 16:47:40 yeah, not memprof level Feb 21 16:47:44 this would be need to be app level Feb 21 16:47:46 owen_: oh, right, it can't just attach... Feb 21 16:47:55 it would be useful for finding out leaking apps too Feb 21 16:49:33 i don't think it would be hard to make a memprof-like tool that resulted in a usable desktop Feb 21 16:49:37 for a high level machine Feb 21 16:50:07 BenM: Well, not memprof-like, in having calltree information.... Feb 21 16:50:18 so to get people engaged, let's divide the problem into desktopwide usage (e.g. toolkit level), and app-specific usage (the pigs) Feb 21 16:50:26 (I'm thinking of how to organize the wiki) Feb 21 16:50:33 federico, i already did that part :-) Feb 21 16:50:39 oh? Feb 21 16:50:40 * federico reloads Feb 21 16:50:45 owen_, my profiler for c# does that Feb 21 16:50:48 and results in usable apps Feb 21 16:50:51 BTW, the shm segment overhead (I looked it up) is 96k pixels -- so 400k on a 24 bit display Feb 21 16:50:57 and gets call trees Feb 21 16:51:53 owen_: [just deleted my irc buffer by mistake; did you reply to my thing about only setting up shm if one tries to blit an image larger than a certain size?] Feb 21 16:51:55 BenM: for memprof it depends a bit on the app. If you have a virtual machine, amy be a bit easier to do in-process. Feb 21 16:52:10 --> _Legion_ (~adebarbar@labi.fi.uba.ar) has joined #gtk-devel Feb 21 16:52:10 BenM: is your profiler the only thing the beagle guys used? Feb 21 16:52:17 i think so Feb 21 16:52:22 they tried valgrind, and it fucked on dbus Feb 21 16:52:35 federico_: I didn't see anything Feb 21 16:52:42 oh Feb 21 16:52:58 federico_: Something like that ... though lots of blits of small images could also make shm workwhile Feb 21 16:53:04 yeah, they reported beable was pretty usable with it Feb 21 16:53:21 it doesn't do anything all that different from a memprof like tool Feb 21 16:53:29 it walks the stack on every managed allocation Feb 21 16:53:44 owen: or start with a small buffer (64x64 pixels?) and grow it by powers of two up to the current bound? Feb 21 16:54:03 i have a tool here I hacked that does a similar thing for malloc Feb 21 16:54:11 --> nat_ (~nat@h000f669ef289.ne.client2.attbi.com) has joined #gtk-devel Feb 21 16:54:11 federico: Smaller buffers means more syncs. A smaller buffer is unlikely to win over XPutImage Feb 21 16:54:15 i should write the code that takes the shared library list and dumps things Feb 21 16:54:36 BenM: I really thkink that working with memprof or massif is better than accumulating more not-quite-finished tools Feb 21 16:54:53 yeah, probably Feb 21 16:55:02 (btw, any ideas on why ssp disabled saving in memprof?) Feb 21 16:55:14 The reason that profiling on Linux is a disaster is that everybody hacks omething up custom that basically works one-off, then it falls into disuse Feb 21 16:55:43 yeah, i sorta didn't start with memprof because it was refusing to work with mono Feb 21 16:55:47 i should really look into that Feb 21 16:55:55 owen_: I'm thinking of things like applets; do they ever blit something bigger than ? Feb 21 16:56:26 federico: Basically he wanted to make some changes to recursive functions and didn't want to figure out how to fix saving, I think Feb 21 16:57:22 ah, ok Feb 21 16:58:51 BenM: I'm not sure that memprof is that applicable to mono, though certainly a tool that could memprof the C bits and do something else for clr bits and merge the results in display would be cool (and much work...) Feb 21 16:59:13 well, memprof is for the metadata that we allocate Feb 21 16:59:18 and for leaks in the metadata Feb 21 16:59:45 i'd love a managed + unmanaged thing Feb 21 17:00:15 BenM: So memprof'ing the runtime itself. Yeah, I'd expect that to work offhand. But memprof is sadly fragile and getting worse with compiler optimizations that break simple backtraces Feb 21 17:00:33 i think the problem is that we fork Feb 21 17:00:44 to make our io-layer daemon, i can actually work around that Feb 21 17:00:49 i'll have to play with it a bit more Feb 21 17:00:54 i have been using valgrind Feb 21 17:01:10 --> mathrick (~mathrick@195.116.35.55) has joined #gtk-devel Feb 21 17:01:14 (and with quite a bit of success, mono has really gone on a diet) Feb 21 17:01:18 Shouldn't actually be a problem.... there were some fixes maybe 6 months ago for problems with forking Feb 21 17:01:26 ah, haven't tried it since then Feb 21 17:01:31 i'll give it a shot Feb 21 17:02:10 anyways, i know how i can avoid forking to make thigns a bit easier Feb 21 17:02:19 But valgrind/massif is pretty decent and what I tend to recommend to people. memprof has less runtime overhead by a large factor and maybe a better GUI (though the kcachegrind widget is pretty cool), but if it doesnt' work... Feb 21 17:02:38 * mathrick waves his drink with little paper umbrella for a while Feb 21 17:02:48 well, it takes me *ages* to start up monodoc with valgrind Feb 21 17:02:58 and i am not even going to try monodevelop Feb 21 17:03:36 even with valgrind --tool=massif ? Feb 21 17:03:58 i like the the --tool=addrcheck output better Feb 21 17:04:10 i'll have to double check the massif speed Feb 21 17:04:53 owen_, what exactly is so fragile about memprof, other than the backtraces Feb 21 17:05:36 BenM: It is overloading random symbols in the libc internals Feb 21 17:05:44 could someone throw a little backlog at my general direction? thanks Feb 21 17:06:01 mathrick, hold on Feb 21 17:06:46 http://primates.ximian.com/~bmaurer/GIMPNet-%23gtk-devel.log Feb 21 17:07:38 owen_, yeah, but that shouldn't be all too fragile Feb 21 17:08:02 BenM: thanks Feb 21 17:09:04 BenM: No? Feb 21 17:09:30 to just get malloc and friends Feb 21 17:09:44 or do they do more than that Feb 21 17:09:49 Experience says it takes about a day every six months to get it reasonably working again. But I really haven't touched it for 1.5 years or so Feb 21 17:10:36 It's more than that ... there are internal aliases ... __malloc() or whatever. There are issues with bootstrapping issues on startup. And there is recently the problem that libc has started protecting itnernal symbosl against overriding. Feb 21 17:10:55 yuck Feb 21 17:11:10 It's a pretty grotty, really. Feb 21 17:11:23 Take a peak at memintercept.c Feb 21 17:11:32 yeah Feb 21 17:11:48 otoh, valgrind is essentially doing the same thing Feb 21 17:11:53 but also rejitting Feb 21 17:11:59 When I tried recently, the interceptions seemed to be right, but there were some interal frames that were showing up and confusing the overall stats Feb 21 17:14:03 i'll try it out here Feb 21 17:15:08 <-- jpe has quit (Ping timeout: 600 seconds) Feb 21 17:15:58 owen_, what kind of experience is GNOME today on a system with 128 or 256 MB of ram Feb 21 17:16:02 i've never tried myself Feb 21 17:16:45 BenM: I haven't tried too recently. My impression is that the core desktop just fits in 128M, but as soon as you start an app you'll be screwed Feb 21 17:17:26 BenM: 256M you should be OK with just the desktop and maybe an app or two... but the standard set of firefox+evolution+ooo would drive you into swap easily Feb 21 17:18:26 yes Feb 21 17:18:37 epiphany + evolution + ooo on a 256 mb laptop is really slow Feb 21 17:18:52 every time you switch windows to another program, it swaps for 2 or 3 seconds Feb 21 17:19:01 that doesn't sound liek fun Feb 21 17:19:10 BenM: it's far from fun :) Feb 21 17:19:47 launching a small app like gnome-calculator also swaps Feb 21 17:20:17 that could probably be helped by fontconfig doing mmap Feb 21 17:20:46 would it? isn't that particular case more of having three pig apps running? Feb 21 17:21:09 say you save a few hundred KB per process, so about 5 MB for the whole desktop Feb 21 17:21:14 yeah Feb 21 17:21:18 but if it is shared Feb 21 17:21:21 any of those apps will eat through that quickly Feb 21 17:21:23 it likely never gets swapped out Feb 21 17:22:04 --> jpe (~jpe@pool-151-203-108-239.bos.east.verizon.net) has joined #gtk-devel Feb 21 17:22:19 I wonder how much of that swapping is code vs. data Feb 21 17:22:30 ah, thats the other intersing thing Feb 21 17:22:33 there are three huge platform stacks running there at the same time Feb 21 17:22:34 something like grope Feb 21 17:22:49 so every time you get an expose, you have to drag in the whole toolkit Feb 21 17:23:12 are there any tools that will tell you which pages of a file got paged in Feb 21 17:23:26 i've actually wanted something like that for mono on what parts of the .dll file we load Feb 21 17:23:36 * jrb would go with gnome-office for a 256 meg machine, if possible Feb 21 17:24:26 Can I add an item to the agenda today, or is too late? Feb 21 17:24:47 BenM: Not that I'm aware of, I've discussed it with some of our kernel hackers and they seemed to think it would be pretty easy to do such instrumentation Feb 21 17:25:13 jdahlin: Just launch into it, though since matthias isnt' here, that limits the effectiveness of conversation to some extent Feb 21 17:25:23 owen_: right Feb 21 17:25:31 owen_, i'd love to see that; i'll talk to rml too Feb 21 17:25:50 I'd like to discuss the possibility of moving libglade (or similar functionallity) into gtk+ Feb 21 17:27:03 Oh, so I'm not interrupting anything, is the memory topic is finished? Feb 21 17:27:16 is the memory topic *ever* finished :-) Feb 21 17:28:02 Right, so I'll just steal the spotlight Feb 21 17:28:03 jdahlin: We've discussed it in the past and been generally positive on the idea (though not on a libxml dependency), but it's pretty much out for 2.8 at this point, I'd say Feb 21 17:28:03 so, can something do code reordering these days? Feb 21 17:28:11 --> bal00 (~hector@155.Red-80-38-207.pooles.rima-tde.net) has joined #gtk-devel Feb 21 17:28:22 federico, nat's grope can Feb 21 17:28:26 federico: There are some perl scripts to write linker scripts floating around, but basically no Feb 21 17:28:26 owen_: There already is a patch in bugzilla that removes the libxml dependency, so I don't think that's a particular issue Feb 21 17:28:50 federico, that sounds more like a distro issue Feb 21 17:29:03 The reason for bringing this up is that there seems to be a lot of activity in the gui builder department lately Feb 21 17:29:10 jdahlin: replacing with gmarkup? Feb 21 17:29:17 jrb: yes Feb 21 17:29:29 BenM: I think nat_ would agree that grope was never much more than experimentware. And now it's 6-year-out-of-date experimentware Feb 21 17:29:57 heh, yeah Feb 21 17:30:06 one could also use the intel compiler to build a distro i guess Feb 21 17:30:08 * federico remembers nat hopping around in his talk to illustrate simulated annealing Feb 21 17:30:27 jrb: http://bugzilla.gnome.org/show_bug.cgi?id=139821 Feb 21 17:30:44 BenM: But on the other hand, I think the groundwork is there to make picking up the question these days a lot easier than when nat tackled it Feb 21 17:31:30 Stuff that was experimental in the toolchain is standard now, a valgrind skin could be used for data collection, etc. Feb 21 17:31:53 owen_: why do you think it's too late for 2.8? Feb 21 17:32:08 <-- alejandro has quit (Remote closed the connection) Feb 21 17:32:57 jdahlin_: There is a fair bit of major stuff scheduled for 2.8 already... Cairo, introspection, maybe gail integration. Adding another major component at this point sounds hard. Feb 21 17:34:30 owen_: I'm not sure if I agree that it has as big impact as the other items you mentioned. Sure it's a fair amount of new code Feb 21 17:34:34 jdahlin: I don't know much about libglade, but even glade doesn't support setting up a treeview easily, for example Feb 21 17:35:00 federico, if you want an easy treeview, use gtk# 2.0 :-) Feb 21 17:35:05 federico: Adding GObject support to libglade would partly solve that Feb 21 17:35:15 federico: see 69639 Feb 21 17:35:20 federico: unless you're refering to storing the actual data in the xml files Feb 21 17:35:50 jdahlin: but we want that to for eg. combo boxes Feb 21 17:36:16 jrb, I guess CDATA could be fine for very simple models, like the ones in combo boxes Feb 21 17:36:22 jrb: right Feb 21 17:36:53 lgs: I'm okay limiting it to simple types like strings and ints Feb 21 17:37:10 lgs: GMarkup doesn't support CDATA iirc Feb 21 17:39:03 jdahlin: just the number of columns, their titles/etc, and which cell renderers each will used (and their packing, etc.) Feb 21 17:39:21 jdahlin, what's the status of updating libglade? Feb 21 17:39:25 hopefully with symbolic names for column ids, or something Feb 21 17:39:49 federico, so you promised to update the wiki with the memory ideas, right ;-) Feb 21 17:39:58 yeah, I'll do that Feb 21 17:40:08 federico: okay, sounds good, but we need to extend the format for that Feb 21 17:40:17 federico: what would you use for indicating the renderers? some kind of introspection? Feb 21 17:40:32 jpe: frozen, pending action from jamesh Feb 21 17:40:58 Chipzz: probably have a list of hardcoded, stock renderers (text, pixbuf, toggle, combo), and an option to use a custom renderer Feb 21 17:41:18 jpe, see the first sentence of Tristan in this email: http://lists.ximian.com/archives/public/glade-devel/2005-February/000990.html Feb 21 17:41:53 BenM: also, I'd love to have some tutorial-like documents on how to avoid scattered data structures Feb 21 17:42:11 scattered data structures? Feb 21 17:42:13 federico: that would in a way suck for languages in which you can resolve classes dynamically though :| Feb 21 17:42:18 BenM: arrays instead of lisp lists, etc. Feb 21 17:42:29 ah, ok Feb 21 17:42:36 i could come up with a list of `memory tips' Feb 21 17:42:56 tips without profiling is just sil,ly Feb 21 17:43:32 well, tips is nice for making small savings here and there that add up Feb 21 17:44:21 If the bulk desktop memory is going into the firefox and evolution data caches (and I think it is), then tips have to be about how to write data caches Feb 21 17:44:48 oh my god Feb 21 17:44:51 yes Feb 21 17:45:00 no one ever writes caches that evict data Feb 21 17:45:23 everything is just boundless hash tables Feb 21 17:45:34 yeah Feb 21 17:45:53 * owen_ is somewhat guilty there Feb 21 17:46:10 well, another thing is how to make data mmapable Feb 21 17:46:10 We may also need some desktop wide mechanism to indicate memory pressure Feb 21 17:46:12 we all are :) Feb 21 17:46:23 owen_, that'd be awsome Feb 21 17:46:32 mono could use that when there is a nice gc Feb 21 17:46:45 grep for '^ *static GHashTable'... :) Feb 21 17:49:21 owen_: that would rock incredibly, if evo could just see when there's mem shortage and time to limit caches a bit Feb 21 17:49:36 also, gecko is *very* big offender here Feb 21 17:49:54 <-- lgs has quit (Leaving) Feb 21 17:49:54 yeah, i have to kill firefox every few hours Feb 21 17:50:09 it starts taking up absurd amounts of ram Feb 21 17:50:13 note that any settings to mem cache size are NOPs in gecko Feb 21 17:50:26 marc markdrago mathrick Feb 21 17:50:28 mathrick, omg Feb 21 17:50:32 I can easily have it use 180MB with 40MB set as limit Feb 21 17:50:44 BenM: yes, it's been there since day 0 I think Feb 21 17:50:48 never got fixed Feb 21 17:50:59 no fucking wonder i have to kill it Feb 21 17:51:00 BenM: I suspect firefox is leaking X resources Feb 21 17:51:05 Chipzz, yes Feb 21 17:51:07 BenM: and that nice bug where closing tab does *not* free its mem Feb 21 17:51:08 i sense that too Feb 21 17:51:36 BenM: since the memory leak doesn't go away when closing tabs, and when you exit firefox X mem usage goes down _a lot_ Feb 21 17:51:45 Chipzz, yes Feb 21 17:52:04 so i am not the only desktp user with that problem ;-) Feb 21 17:53:28 no Feb 21 17:53:35 gecko is total killer Feb 21 17:53:40 BenM: I actually suspect the flash plugin Feb 21 17:53:44 but this is getting off-topic Feb 21 17:53:51 i have considered removing flash Feb 21 17:54:04 flash is totally crappy, but even w/o flash gecko can kill all mem hands down Feb 21 17:54:06 why am i giving my memory to advertisers Feb 21 17:54:33 Chipzz, its not *really* off topic. Guess who users will blame for their computers slowness: Feb 21 17:54:43 btw, for evo, it helps to empty trash, it syncs its mmap()ed areas or something, I can sometimes get 100MB this way :) Feb 21 17:54:45 BenM: firefox? :P Feb 21 17:54:45 1) Linux 2) GNOME 3) Mozilla Feb 21 17:54:58 most likely 1, but possibly also 2 Feb 21 17:55:04 BenM: most users aren't even aware that firefox uses gtk+ Feb 21 17:55:06 oh, 4) Fedora/SUSE/NLD Feb 21 17:55:18 Chipzz, yes, but it looks like gnome Feb 21 17:55:41 its the same reason why fontconfig has alot to blame for gtk+ Feb 21 17:55:51 BenM: by the same reasoning you could blame gnome for ooo starting up really slow ;) Feb 21 17:55:55 BenM: I do blame linux, at least here it seems to stall when something mallocs and hits swap, even if nothing else needs mallocing at the moment Feb 21 17:56:00 Not only that, but one app eating memory slows down the whole system Feb 21 17:56:18 owen_: shouldn't the leakage get swapped out in theory? Feb 21 17:56:24 in theory Feb 21 17:56:29 and stay swapped out Feb 21 17:56:55 even so, it takes time for stuff to get swapped out Feb 21 17:57:10 BenM: FWIW, I was happily running 1.4 in 64MB and hitting swap was rare occasion... I used gecko sparingly then, since I had no connection, but still, 64MB was more than enough Feb 21 17:57:30 nowadays, I have 512MB and too often wish for more Feb 21 17:57:40 i kill things even with 1gb Feb 21 17:57:49 right Feb 21 17:58:11 natuilus, firefox-bin, gnome-panel, evolution, wnck-applet Feb 21 17:58:22 oh, and gnome-terminal Feb 21 17:59:00 yes Feb 21 17:59:13 nautilus is rather well-behave Feb 21 17:59:14 d Feb 21 17:59:24 only thumbnailing makes it go awry sometimes Feb 21 17:59:29 <-- pbor has quit (Leaving) Feb 21 17:59:30 not for me Feb 21 17:59:40 i am on nld, so i may be seeing already fixed issues Feb 21 17:59:49 --> fatal (~fatal@i.do.toomuchwork.net) has joined #gtk-devel Feb 21 17:59:54 I am on not so recent Sid Feb 21 18:00:02 very not recent in fact Feb 21 18:00:09 and quite broken :> Feb 21 18:00:20 thats why i am not on debian :-) Feb 21 18:00:30 oh, it's not because of debian Feb 21 18:00:45 but because my current account is about 4 years old I think Feb 21 18:01:09 I have had 1.4, 2.2, 2.4, 2.6, and now most of 2.8 installed on it Feb 21 18:01:17 * BenM has not even used linux for 4 years Feb 21 18:01:37 --- mitch is now known as miZzz Feb 21 18:02:01 BenM: everything breaks when you accumulate random settings from 4 years and 5 versions :) Feb 21 18:02:13 <-- loz has quit (Fritter and waste the hours in an offhand way) Feb 21 18:02:15 thats why I *never* upgrade Feb 21 18:02:28 i always do it fresh Feb 21 18:02:59 BenM: oh, yes, but account, do you migrate everything from your user account to fresh one? Feb 21 18:03:07 that's what I'm talking about Feb 21 18:03:16 well, i don't just copy my ~ Feb 21 18:03:23 exactly Feb 21 18:03:26 man Feb 21 18:03:30 and my ~ is 4 years old Feb 21 18:03:36 I have gconf keys from the beginning of time Feb 21 18:03:49 federico, dude, on windows Feb 21 18:03:50 its worse Feb 21 18:03:52 federico: nod Feb 21 18:03:56 registery keys from beginning of time Feb 21 18:04:03 also, we complain about gaim's code quality, but it *does* wipe out old keys on its own config file... Feb 21 18:04:25 --> taf2 (~taf2@141.157.56.42) has joined #gtk-devel Feb 21 18:06:44 so we have crossed the two-hour mark for the meeting, and it's getting quiet Feb 21 18:06:48 shall we adjourn? Feb 21 18:07:04 sure Feb 21 18:07:15 BenM: thanks for starting this, dude :) Feb 21 18:07:18 everyone will love you Feb 21 18:07:22 :-) Feb 21 18:08:55 yeah Feb 21 18:09:55 <-- scristian has quit (init 0)