Discovered that I created a crasher with form controls after printing: hanging anonymous content off the document (via the binding manager) ended up prematurely whacking the content when a new view gets installed on the content model. Moved the stuff over to the pres shell. Seems to fix the problem.

Spent some time tinkering around with my Perl version of "leak soup" after discovering that hyatt checked in some new leaks.

Reviewed hyatt's changes to fix the leaks. Cleaned up my patch for the printing crasher based on dbaron's feedback. scottip found some problems with the thread pane attribute minimization, and I tracked it down to a bug in nsPromiseFlatString. Worked out simple workaround for now. Tried to reproduce a crash in nsXULTemplateBuilder related to atoms, but couldn't.

More mail scrolling analysis. Applied changes from evaughan to "smooth" scrolling. Ripped out time spent in content and frame construction (in other words, RDF, XBL, and CSS frame constructor), and am trying to look at what's left over.

• 25% of the remaining time (or about .25 × .5 = 12% is spent in nsView::Paint(). Almost half of that (11% of the remaining time, or 1.3% overall) is spent in nsRenderingContentWin::DrawImage(), 73% of that time is in 819 calls to StretchDIBits(). Do we need to do a stretch-blit here? Is there another API that might be faster?

Removing all the painting time leaves us with about .5 × .75 = 37% of the total time. Here's how that splits up:

• 60% of the time (or 22% overall) is spent in 19 calls to nsXULTreeOuterGroupFrame::InternalPositionChanged(). This winds through all of the reflow code.
• In the reflow subtree, 10% of the time (or about 2% overall) is spent in 1,460 calls to nsPresShell::StartLoadImage(). This is dominated by 62,258 calls to nsFrameImageLoader::IsSameImageRequest(). Do we need a better algorithm for remembering stuff here?

Removing the reflow subtree leaves us with .4 × .37 = 14% of the time.

• 53% of the time (or 7% overall) is spent in 24 calls to FrameManager::ComputeStyleChangeFor(). 9 calls are from nsCSSFrameConstructor::ContentStateChanged() and appear to be dealing with tracking mouse events. What's going on here? Are we setting an :active pseudo-class or something? It looks like this might account for much of the time that's spent in the style system: almost a third of the time in this routine (about 3% overall) is down in SelectorMatches()
• Slicing it a bit differently, 43% of the time, or about 6% overall is spent in 19 calls to nsEventStateManager::ChangeFocus(). Why are we changing focus at all?
• 27% of the time, or about 3% overall, is spent in 150 calls to nsEventStateManager::PreHandleEvent(). About 70% of that time, or 2% overall, is spent in 20 calls to nsEventStateManager::GenerateMouseEnterExit(), all of that going to nsEventStateManager::SetContentState().

Based on this, it looks like we either have way too many style rules triggering off of the focus state of the scrollbar, or we're just pushing too much shit down into the style system. Removing this stuff could save us up to 10% of the time spent in page-down mail scrolling.

Argh. It turns out that all the focus and blur junk is coming from the fact that I have to switch windows to actually profile the app! There are only two calls that amount to any significant portion of the time. Doh!

The fact remains, though, that we do fire plenty of style re-resolution when changing the :active state of the scrollbar. Most of the pseudo-rules are coming from ua.css: why would we need this for chrome?

Went two more rounds on bug 53969, incorporating some excellent feedback from dbaron. Starting to feel good about the patch.

scc got his fix checked in to create Substring's from iterators. With that in, I went ahead and changed ParseAttribute() to use iterators, too. Quantify says the speedup wasn't as big as I'd hoped. In the bug I say I expect to see this change pick up about 2.5%; in reality, we move the time from CharAt() inline and pick up a bit of an improvement (maybe just shy of 1%). Oh well.

Poking around, I do see that we're spending an awful lot of time in Compare() (from Rule::LookupSymbol()) trying to figure out if we've got the right variable. We get almost a ten-fold fanout; maybe we should build a little hashtable to avoid this? (The net win is another 1%, tops: I'm seeing this as 1.27% of the time...)

All-day meeting today. Mostly talked about how to reduce footprint for embedding needs.

Looked a new window creation from the XUL cache. 58% of the time is spent in nsXULDocument::ResumeWalk(). This breaks down as follows. ("Overall" numbers adjusted to reflect total time of opening new window, not percentage of ResumeWalk().)

• About 35% (20% overall) of that time is spent in the initial reflow.
  • 36% of the time (7% overall) is spent in 57 calls to nsXBLService::LoadBindings(). 60% goes to nsXBLBindings::InstallProperties() (mostly spent in 11 calls to nsJSContext::EvaluateString()), 30% to nsXBLBinding::GenerateAnonymousContent() (mostly spent in 57 calls to nsXMLElement::CloneNode()).
  • 14% of the time (3% overall) is spent in 22 calls to nsPresContext::ReParentStyleContext().
• About 25% (15% overall) is spent in 22 calls to nsXULDocument::LoadScript().
  • Half that time (7% overall?!?) winds up in two calls to nsXULElement::GetScriptObject(), apparently retrieving the -moz-binding property value from the nsIDOMCSSStyleDeclaration. This ends up down in the bowels of the style system resolving the style on something. Should look into this.
• About 17% (10% overall) is spent in nsXULDocument::ResolveForwardReferences().
  • 50% of the time is spent in nsXULDocument::AddSubtreeToDocument().
  • 25% of the time (2.5% overall) is beneath that: spent in nsXULDocument::CheckBroadcasterHookup() hooking up broadcasters.
  • 16% of the time (1.6%), still beneath AddSubtreeToDocument(), is spent in 19 calls to nsXULTemplateBuilder::CreateTemplateAndContainerContents(). This is to be expected.
  • Slicing this a different way, 62% of the time (6% overall) is spent in 1,014 calls to nsXULElement::SetAttribute(). This is dominated (60%) by 290 calls to nsXULElement::EnsureSlost() (about 4% overall).
  • 30% of the time (3% overall) is spent in nsXULElement::SetDocument(). Strangely, we have 183 calls to SetAttribute() here that dominate the calls: ah, it's the "reset" hackery that forces event handlers to get re-compiled.
• 6% of the time is spent in two calls to nsJSContext::InitContext().

Had to cheer hyatt up. He felt grouchy and neglected after the meeting.

Collected bloat stats for Linux. Pushed around some layout bugs.

Checked in fix for the printing bug on the trunk. Still awaiting PDT lovin' for the branch.

Fixed a problem in nsLineLayout::FindNextFrame() that had been festering since I'd nuked nsTextRun. Fixed the problem with nsGfxScrollFrame that was causing 'em not to be recycled. Checked in the fixes for attribute minimization on the trunk.

Poked around a bit at a bug with pseudos: looks like we might be matching text frames. Worked up a patch, but buster took the bug back, as it looks like he may have introduced the regression. Filed a couple bugs tryin' to eat dogfood.

Helped from the peanut gallery with a bad GC problem that turned out to be a slip when jst was fixing some other bug. Took a stab at re-writing radha's patches to make the URL bar history actually roll off names.

Helped radha finish off the patch for fixing the URL bar history, using RDF:Seq and limiting the number of elements that wind up in localstore.rdf. Figured out why you couldn't drag bookmarks into a folder, ended up being an ancient bug in the XUL template builder. Dug around a bug that has to do with a page that's rendered too wide: turns out to be a block-in-inline problem.

Fixed a problem with nsXULTemplateBuilder::RemoveMember(): it was being too liberal with respect to the content that it blew away. We needed to walk up the template hierarchy in parallel with the generated hierarchy to detect if something was "really" a member. Checked in change to XUL template builder to use iterators instead of CharAt().

Worked up a fix for clearing history from the prefs panel at claudius' prompting.

Stayed up late tinkering around with libbfd and stuff trying to figure out where all the space in the layout DLL is going, and if it's possible to "fold" function implementations. Mostly just stumbling around source code at this point...

Little bit more tinkering with readelf. Brendan and I discovered that 300KB of libgklayout.so is vtables! Wow!

Stayed up late looking at a problem with I18n folders in AIM (Bugscape bug 2856). They just don't work, and I can't figure out why. There are a couple minor problems with nsCAimDataSource, but the root of the problem seems to be in nsXULTemplateBuilder: it's not picking up the right value for the empty attribute, apparently on async notification to the folder. I tried to reproduce using vanilla RDF/XML, but to no avail. Strange...

Radha's fix for the URL bar history ended up revealing a latent bug because it exercised a heretoforth unused code path in nsRDFXMLDataSource's serializer! Whee! Figured out Bugscape bug 2586: couple of evil NS_ConvertASCIItoUCS2() calls lying around. Checked in the implementation for clearing history onto the trunk.

Spent the day plugging away at ELF analysis. It turns out that even thoug 7% of the symbols point to redundant functions, the redundancy accounts for about 1% of the .text segment in libgklayout.html. I did discover that we've got about 250KB of IID declarations (e.g., iid.123); I presume these are from nsIFoo::GetIID() implementations. Posted a summary of what I found.

Prodded at some heap allocation data for a while. Talked with dougt about analyzing the "leveling off" behavior that he's observing with memory usage in the gtkEmbed program.

Figured out the "real way" to bullet-proof ResumeWalk(); ended up being caused by a botched attempt to bullet-proof a similar bug! Fixed up the patch for clear global history to include bienvenu's feedback. Spent some time looking at the topcrash data, and filed a bug for the RDFServiceImpl crash.

Split up tasks for doing this "preliminary memory analysis" with edward.

Gathered gross dynamic footprint data using gtkEmbed for preliminary memory analysis. Started writing a document.

Followed up on the topcrash bug I filed earlier this week (mostly because heikki filed a another one). I found two more places where we weren't matching RegisterDataSource() calls.

Some more twiddling trying to collect leak data; not much luck with Boehm stuff. Helped warren et al. untangle the build mess that was PRINTF().

Finally got the fix checked in for the XUL document bulletproofing. Continued wandering around trying to nail down leaks. I think what I'm going to do is just go with what the bloat log spits out for now, and call it a "conservative estimate" of leaks. I've got a script that runs through incrementally more and more URLs on the buster, and dumps the bloat logs to successive files. I'll figure out how to post-process this somehow. I also want to compare against seamonkey: I'm suspicious that seamonkey isn't leaking as much as gtkEmbed (e.g., possibly because of some broken ownership evil in gtkEmbed).

Put together a graph that shows shutdown leaks as a function of number of URLs visited. Did some analysis of the "largest libraries".

Long session with vidur, warren, jud going over memory and embedding task list. Late night gathering last-minute data for hamerly's meeting tomorrow. Landed RDF crashproofing on the trunk; hopefully we'll see some good news in a few days.

Present memory information. Ran quick-and-dirty profiles on folder switching and sorting for discussion with mailnews guys.