Description

Build 593 Q2C27

After resuming, closing and deleting many entries in the journal, the journal icon took up a large portion of the donut in the home view. I actually deleted everything from the journal, as we were checking to see if the files were being deleted from the datastore.

After typing "top" in the terminal, and finding the entry for the Journal, it said it was using 13.3% of the memory. However, it was taking up at least a third of the donut.

Doing "ps aux|grep Journal", deleting 10 or 20 journal entries, and then doing "ps aux|grep Journal" again shows that the Journal's memory usage according to ps *does* increase when you delete entries. Likewise, adding up just the anonymous (ie, heap memory) mappings from pmap for the journal also shows steadily increasing usage as you delete things. So the donut *is* telling the truth: the journal is steadily using more and more memory.

As for the exact percentages, ps/top's "%MEM" column measures the percentage of *total* RAM used, while the activity ring ignores the RAM used by system processes. So you shouldn't expect them to match.

That said, I can't explain why the journal would take up 1/3 of the ring with an RSS of 30M and 100M free memory. The actual measured memory usage should be less than the RSS, so it should take up less than 1/4 of the ring. So there seems to be some degree of measurement error here, and it might even be that the measurement error is getting worse as the journal uses more memory.

The leaks, while not being as critical as the donut would make you think, are still really bad. I started investigating it and they seem at least partially caused by pygobject, which sucks because we are using it extensively in all the code base. I'll keep investigating...

While turning it off is probably prudent until it is more accurate, I would suggest that we increase the size of the sector each activity takes in the donut to discourage launching too many activities at once. Maybe 72 degrees per activity to suggest 5 max (including the journal)?

6 is fine. I did notice that the second (and third...) instance of browser when launched from within the browse activity itself was no longer generating an icon in the donut--has that be sorted out since removing the memory-usage mapping? (It is important, because it is the only way to switch between windows.)

Oh, on second thought, perhaps 5 is best, to be conservative (and because i've just had a crash on starting Read as the 6th). Regarding the new Web window not appearing on the donut, I think there's a open ticket about that (more especifically, about how to handle pop-up windows).

Honestly I don't have a clue about the possiblity to get this working well in 1.0. I'm not sure what it would take. Since both jg and danw seem to skeptic about it though, I think we should consider a different solution on the short time.

We agree with Walter idea and we suggest punting the real memory-usage based one to post 1.0.

OK, we'll see how it goes this week, and if it works better than before, we'll leave it in; else we'll pull it. I don't think we should be spending time trying to fix it right now; either it now works well enough, or we should disable it again.