On Wed, Dec 03, 2014 at 10:33:59AM +0100, gregor herrmann wrote: > On Wed, 03 Dec 2014 00:43:37 +0100, Jan wrote: > > > > This looks better, doesn't it :) > > > PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command > > > 31723 gregoa 20 0 556M 60748 19616 S 0.0 1.5 12:30.11 ./dianara > > > 5789 gregoa 20 0 1752M 628M 44124 S 4.8 16.4 2h13:06 iceweasel > > It looks a lot better! > > Does this difference apply to similar usage, with same number of posts > > per page, same update interval and running for a similar amount of time? > > Even so, memory usage depends greatly on what's in the posts, of course. > > I guess that my usage and settings should be roughly the same and ... > > > But you also say that now the memory usage stays constant, so it sounds > > very promising =) > > ... that's indeed the most pleasant experience. > > > > With the help of a friend and qtcreator's nice valgrind integration I > > > created a patch which adds parents to some objects (so that they are > > > auto-reaped) or manually deletes them. > > I find it a little strange that it really fixes things, mainly because, > > from what I've seen by giving it a quick look, the fixes are mostly > > specifying the parents of several objects, and manually deleting others. > > That's correct. > > > The reason those objects (at least, most of them) don't have a parent > > set, is because they're re-parented when they're managed by a QLayout. > > There's of course, the possibility of Qt bugs and that not being handled > > correctly. > > Yeah, I'm a bit confused as well. > > My current understanding is that this re-parenting only works for > elements which are added to others with addWidget() or addItem() and > friends, but not for others which just are created and then linger > around. > > And that's also why I added parents (more or less) only to this kind > of elements and not to all. > > > The same applies to the manual deletion of some widgets in > > Comment(); those are supposed to be properly deleted automatically when > > the parent Comment() object is destroyed. > > Right, that's a mystery to me as well. Those labels are all added to > layouts after all. > > But valgrind complained about not deleted labels. Adding "this" led > to layout changes (?!), that's why I tried to delete them manually in > the destructor. > > > There are also a few objects which will live as long as the program does, > > so those are not really a concern either way (tray icon, menus, qoauth > > handler...). > > Ok, it's quite possible that i was a bit over-enthusiastic :) > > > > I'll investigate, thanks again! > > Thanks!
OK, after some deeper reading and some testing, it really seems to help. Even considering the great variations in content that can happen in the timelines, moving around several pages and then going back to the newest doesn't seem to leak much memory now. And by checking out these changes I realized a couple of places where widgets are initialized without a parent, because they'll be added to a layout later, _but_ in these places, adding them to a layout is conditional. That's a sure leak right there ;) Also, setting the parent initially doesn't hurt, and makes it safer in cases like these, so it's a good change. The only issue I've seen is a certain label that shouldn't be visible in certain situations but now, having always a parent, is. But that's one of the leaks precisely because of that, so I'll be fixing this properly. I'll be merging these to master on a file-per-file basis for clarity, and change a few things in the way. The BTS suggests that there's a patch that could be used for Dianara, but I guess we're in agreement that these only applies correctly to current master and can't be safely applied to v1.2.4 without further changes. I'll be releasing 1.2.5 in about 2 weeks, but I guess that's out of the question for Jessie. (BTW, semi-offtopic, v1.2.4 still hasn't entered Testing due to freeze block. Should I ping Mònica? =) Thanks a lot, again, for your patch, it was very helpful! Cheers! o/ -- Development blog: http://jancoding.wordpress.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
