Met with guys from Intel to go over memory leak tools: covered the refcount balancer and Brendan's bloatblame.
Continued working on the O(n2) joy I've created in mailnews. Almost working, just got to figure out why flagged messages are bombing...
So it turns out that the mailnews implementation of
OnChange always sends null as the old
target. Oops! I suppose there's probably no way to get them to fix
this, so I need to go back and figure out if my sloppy-map idea will
work.
Wow. This is tougher than I thought. I spent most of yesterday banging
around this binding support stuff. So far. I've made it so that we
recompute the minimal set of bindings, and we compute bindings
lazily. I've also gone through and renamed the old variable-to-value
assignment objects from nsBinding to
nsAssignment, to distinguish it from the stuff that deals
with the <binding> tag.
That said, I think I'm coming to a new realization with respect to how to index the binding support table. I'm back to the idea that it should purely be indexed by assertion source resource; not a partial <source, property> tuple. The trick is to only add matches to the table whose bindings depend on a property and target leading out of the source. Previously, I was putting every match that involved the source into the table, so I'd pick up all of the children of a folder, for example.
Argh! So close, but I still have a serious problem with the lazy binding computation. I've gotten everything working for the "simple" case, and am now trying to get the "extended" case to work. What's screwing me is that I'm being too lazy. If I've got a value that depends on another binding being computed, I'll never compute the first binding!
A kludgy way around this is to force the initialization to eagerly compute any "parent" bindings.
Finally got my stuff checked in late last night without too much
trouble. Things are looking much better today. I found another 20-30%
(!) by just removing all of the attributes from the
<treeitem> in the threadpane template, and filed a
bug
on putterman to fix that.
Met with Troy to talk about doing layout stuff. Implemented
rebuild() for XUL templates.
Grovelling through this list-item bug. Thought I'd try to keep track of stuff that I'd noticed that may be worth measuring later for performance reasons.
Not sure how expensive it is to grovel over a text node trying to
determine if it's only whitespace or not: we certainly do it
frequently enough during reflow; see
nsLineLayout::ReflowFrame().
Should look for this to turn up during Quantify runs. It would
certainly be easy enough to cache this using a bit somewhere.
With respect to
38832,
dbaron pointed out that my solution will end up creating problems if
you; e.g., set a background-color on the
<ul>. Sigh: back to the drawing board. I'm going to
let that one smoulder for a while, and try to tackle
36401,
which is this "splitting frames" problem.
Now, IIRC, the idea is that you have a block frame contained inside an inline frame; e.g.,
<p><span>here is <center>a block</center> in an inline</span></p>
CSS2 doesn't allow blocks to be contained inside inlines, and since this situation can't be detected at document parse time (because display type hasn't been determined yet), we need to "fix it up" after the fact:
p
/ | \
/ | \
/ | \
span (span) span
/ | \
"here is" center "in an inline"
|
"a block"
The original span is split into three parts. The first
and last are just inline frames. The middle is an anonymous block
frame (indicated by (span) frame) is created that parents
the real block tag, in this case, the center.
The problem is that this screws with
nsCSSFrameConstructor::GetPrimaryFrameFor().
So when nisheeth and I talked on Thursday, he said that there were three things that needed to be done here.
Change a "special" frame (that is, one that has been split) such that it has as a frame property the primary frame that it came from.
Add a bit to the frame that indicates whether or not the frame is special, so that you don't need to do a hashtable lookup for each frame.
Finished up the changes that nisheeth and buster wanted me to make for 36401, buster says he thought they looked okay, so I'll see about getting 'em checked in RSN.
For shits and giggles, I thought I'd run a profile on the PNG2HTML page, which was apparently a performance hotspot at one time.
After making my changes, I don't see IsSpecialFrame() on
the radar anywhere (it's an inlined bit check, so I really was hoping
not to!). That said,
nsLineLayout::NewPerFrameData() is coming up as a big
::operator new() consumer, calling it 5,100 times and
accounting for about 3% of the focus. I wonder if we could use
evaughan's arena stuff for that?
nsTextFrame::ComputeTotalWordWith() is called 47 times,
and accounts for 7.21% of the focus! What's going on there? It has
*huge* fanout here, but I'm guessing that it's probably not
worth optimizing because it's such a degenerate case. If it pops up
again in another test, I'll take a look.
Spent a couple hours late-nite tinkering with the bug where non-ASCII
URLs aren't properly getting constructed based on the document's
characeter set encoding, bug
10373.
Implemented
NS_ConvertUCS2toUTF8:
need to get that checked in to fix a bunch of bugs without going
malloc-happy.
Worked up a proof that my changes will actually fix bug 36401.
Finally got my fixes in for fixing the block-in-inline construction stuff, bug 36401.
Banged around and cleaned up my changes for bug 10373.
Architecture meeting to go over warren's changes to the plugin API, start discussing XPCOM.
Landed a while pile of bug fixes, including
NS_ConvertUCS2toUTF8.