The weekly report for week 22.
Read about XPCNativeWrapper and Greasemonkey security issues.
Ported the script to chrome.
Not a full workday.
Learned that the zoom level affects the computed style. I had thought it affected the metrics gfx reports to layout.
Moved to development in the chrome rather than in the test harness. Longer build–run–debug–code cycle than with the test harness.
Leaned how to do it faster.
Found a bug in my previous optimizations.
Unoptimized.
Reoptimized carefully. Saw the same bug.
Concluded that the objects returned by getComputedStyle
are not valid after subsequent calls. Removed part of the
optimization.
Noticed that even when running from chrome, the script is slower than when running in the document. Tried different tricks to no avail.
Learned how to read prefs.
Made the zoom reset to 100% if using the smart zoom when the view is already zoomed to the smart zoom level.
Uploaded a preliminary test patch to the bug report.
Started reading DOM/XPCOM docs.
Read newsgroup archives in the hope of seeing something relevant to the remaining performance problems.
Random thought of the day while hunting for implementations
of nsITextContent: Javadoc rocks.
Posted a the performance question to mozilla.dev.tech.dom.
Read docs. And more docs.
Asked around on IRC. Learned that nsITextContent
is not scriptable.
Started to wonder if implementation in C++ would have been easier than figuring out how to squeeze performance out of JS.
Diminishing returns are kicking in big time, but I don’t want the feature be yanked because of performance concerns.
Packaged the problem as test cases and filed a bug as requested by Boris Zbarsky.
Reading code on LXR again.
Got rid of the precise regexp and started using
isIgnorableWhitespace from inIDOMUtils.
Not touching text node content strings in JS at all. Big performance
win!
Decided to reimplement in C++ to avoid the performance problems of JavaScript. Should have done this earlier.
Started the C++ reimplementation. I figured I might as well learn to get over the first XPCOM hurdles with this bug instead of the next one on my list.
Asked around on IRC for array types. Gecko has lots of those!
Spend a lot of time trying to understand inIFrame
in order to read style data directly from the private interface
without going through the string-based getComputedStyle.
Posted a question to mozilla.dev.tech.layout.
Rewrote the tree walk in C++.
Learned about XPCOM identity guarantees or lack thereof.
Learned to debug Firefox in XCode.
Found out the bug was hidden due to partial builds! (See Tuesday above.)
Other embarrassing newbie mistakes.
Compensated for time lost on Monday.
Wrestled with build misconfiguration.
Corresponded in the newsgroups.
Corresponded in the newsgroups.
In summary, the basic algorithm made sense from the start, was rather straight-forward and gives the desired results. However, in JavaScript it wasn’t fast enough. My expectations of JavaScript performance were totally wrong. Basically the whole week was lost in first trying to make the JavaScript version run faster—without success—and then in learning how to do it right in C++. If I had more experience in this, I would have known to use C++ to begin with and wouldn’t have spent so much time on JavaScript performance. Quite embarrassing really.