<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Taras' Blog</title>
	<atom:link href="http://blog.mozilla.com/tglek/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.mozilla.com/tglek</link>
	<description>Just another Blog.mozilla.com weblog</description>
	<lastBuildDate>Thu, 09 Feb 2012 23:01:54 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>Snappy Feb 9: Blame Canada!</title>
		<link>http://blog.mozilla.com/tglek/2012/02/09/snappy-feb-9-blame-canada/</link>
		<comments>http://blog.mozilla.com/tglek/2012/02/09/snappy-feb-9-blame-canada/#comments</comments>
		<pubDate>Thu, 09 Feb 2012 23:01:02 +0000</pubDate>
		<dc:creator>tglek</dc:creator>
				<category><![CDATA[snappy]]></category>

		<guid isPermaLink="false">http://blog.mozilla.com/tglek/?p=568</guid>
		<description><![CDATA[The meeting was short this time because all of the participating people in the Toronto office conspired be busy or on vacation today. Our UX team helped us decide to turn on tabs-on-demand + do tab restore by default, Bug 711193. This change will make interacting with the browser more responsive after startup, help MemShink and [...]]]></description>
			<content:encoded><![CDATA[<p>The meeting was short this time because all of the participating people in the Toronto office conspired be busy or on vacation today.</p>
<p>Our UX team helped us decide to turn on tabs-on-demand + do tab restore by default, Bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=711193">711193</a>. This change will make interacting with the browser more responsive after startup, help <a href="https://wiki.mozilla.org/Performance/MemShrink">MemShink</a> and not trigger as much captive wifi portal badness.</p>
<p>Frontend people are busy adding telemetry to everything that matters, <a title="NEW - bunch of Firefox frontend telemetry metrics" href="https://bugzilla.mozilla.org/show_bug.cgi?id=671038">bug 671038</a>. Some of this has already paid off in terms of us catching a tab animation regression in <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=724349">bug 724349</a>. We plan to switch our awesomebar searching from SQL to an FTS. If you are a text-search/tokenizer expert, perhaps you help us with <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=725821">bug 725821</a>. There is also a lot of activity on making various sync IO things async, see the <a href="https://wiki.mozilla.org/Performance/Snappy/2012-02-09#Projects">meeting notes</a> for complete details.</p>
<p>Brian Bondy posted an <a href="http://www.brianbondy.com/blog/id/127/">update</a> documenting his two-week rampage through Firefox startup inefficiencies on Windows. Brian&#8217;s blog post contains tips on xperf, Firefox profiler, about:startup &#8211; <a href="http://www.brianbondy.com/blog/id/127/">read it</a>.</p>
<p>The networking team is busy nuking the big cache lock, see bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=717761">717761</a>.</p>
<p>Olli has landed most of the cycle collector fixes. Telemetry shows a dramatic reduction in cycle collection times for Firefox 13. He and Andrew investigating the remaining causes of long CC times.</p>
<p>I&#8217;ll end this post with a pretty picture demonstrating recent cycle collection improvements.<br />
<a href="http://blog.mozilla.com/tglek/files/2012/02/cc13_12.png"><br />
<img class="alignnone size-full wp-image-569" title="Time in milliseconds" src="http://blog.mozilla.com/tglek/files/2012/02/cc13_12.png" alt="" width="739" height="238" /></a><br />
* y: frequency, x: milliseconds</p>
<p>&nbsp;</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.mozilla.com/tglek/2012/02/09/snappy-feb-9-blame-canada/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Snappy, Feb 2nd &#8211; FOSDEM, Help Wanted</title>
		<link>http://blog.mozilla.com/tglek/2012/02/07/snappy-feb-2nd-fosdem-help-wanted/</link>
		<comments>http://blog.mozilla.com/tglek/2012/02/07/snappy-feb-2nd-fosdem-help-wanted/#comments</comments>
		<pubDate>Wed, 08 Feb 2012 00:52:06 +0000</pubDate>
		<dc:creator>tglek</dc:creator>
				<category><![CDATA[snappy]]></category>

		<guid isPermaLink="false">http://blog.mozilla.com/tglek/?p=565</guid>
		<description><![CDATA[We cancelled last week&#8217;s snappy meeting due to Perf/Snappy workweek + FOSDEM. See Jared&#8217;s post for a summary of the workweek, I&#8217;ll mention the rest below. We figured out a strategy for avoiding blocking DOM Storage IO (use scriptblocker to async preload relevant dom storage. Do async writeback to commit). We have a plan for [...]]]></description>
			<content:encoded><![CDATA[<p>We cancelled last week&#8217;s snappy meeting due to Perf/Snappy workweek + FOSDEM. See Jared&#8217;s post for a <a href="http://msujaws.wordpress.com/2012/02/03/firefox-performancesnappy-work-week-recap/">summary</a> of the workweek, I&#8217;ll mention the rest below.</p>
<p>We figured out a strategy for avoiding blocking DOM Storage IO (use scriptblocker to async preload relevant dom storage. Do async writeback to commit). We have a plan for cancellable SQL queries, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=722243">bug 722243</a>.</p>
<p>SetTimeouts/30s telemetry landed in bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=715953">715953</a>, I attached result of that in bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=715376">715376</a>. Persistent telemetry was backed out while Nathan investigates problems, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=707320">bug 707320</a>.</p>
<p>Brian Bondy has been fixing our usage of Windows APIs:</p>
<ul>
<li>bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=722225">722225 </a>- Firefox startup opt on Windows by optimizing D3D10CreateDevice1 (pending review)</li>
<li>bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=722315">722315 </a>- Firefox startup opt on Windows by lazy loading CLSID_DragDropHelper (landed)</li>
<li>bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=692255">692255 </a>- Find a way to get rid of prefetch files on Windows for faster startup (pending review)</li>
</ul>
<p>We spent the weekend at FOSDEM. I re-presented my Plumbers talk on why Linux <a href="http://people.mozilla.com/%7Etglek/lpc2011">sucks </a>for starting big apps. I also did a <a href="http://people.mozilla.com/%7Etglek/fosdem2012/">Telemetry talk</a>. The audience was great.</p>
<p><strong>Help Wanted</strong></p>
<p>To my great regret, I forgot to mention that Mozilla is <a href="http://www.mozilla.com/en-US/about/careers.html">hiring</a> in my talks. In particular, I&#8217;m looking for more performance hackers. If enjoy spending quality time with stack traces,writing profilers or analyzing performance logs leave a comment or send me an email. Compiler toolchain and/or kernel hacking experience would be a great bonus.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.mozilla.com/tglek/2012/02/07/snappy-feb-2nd-fosdem-help-wanted/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>At BetaGroup in Brussels</title>
		<link>http://blog.mozilla.com/tglek/2012/02/02/at-betagroup-in-brussels/</link>
		<comments>http://blog.mozilla.com/tglek/2012/02/02/at-betagroup-in-brussels/#comments</comments>
		<pubDate>Thu, 02 Feb 2012 10:01:50 +0000</pubDate>
		<dc:creator>tglek</dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://blog.mozilla.com/tglek/?p=559</guid>
		<description><![CDATA[As the outside temperature reached -10C, the DIY heating system at hackerspace.be proved insufficient. On Wednesday the Perf/Snappy workweek was relocated to BetaGroup Coworking Brussels. We&#8217;ll be here until FOSDEM. Betagroup Coworking Brussels is an industrial-strength coworking space with lots of desk space, internet, kitchen, ping-pong and a bunch of heavy metal&#8230;]]></description>
			<content:encoded><![CDATA[<p>As the outside temperature reached -10C, the DIY heating system at hackerspace.be proved insufficient. On Wednesday the Perf/Snappy workweek was relocated to <a href="http://coworking.betagroup.be/">BetaGroup Coworking Brussels</a>. We&#8217;ll be here until FOSDEM.</p>
<p>Betagroup Coworking Brussels is an industrial-strength coworking space with lots of desk space, internet, kitchen, ping-pong and a bunch of heavy metal&#8230;</p>
<p><img src="http://farm8.staticflickr.com/7168/6800567379_2c052c4f55_z.jpg"></p>
]]></content:encoded>
			<wfw:commentRss>http://blog.mozilla.com/tglek/2012/02/02/at-betagroup-in-brussels/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>fast DXR</title>
		<link>http://blog.mozilla.com/tglek/2012/01/31/fast-dxr/</link>
		<comments>http://blog.mozilla.com/tglek/2012/01/31/fast-dxr/#comments</comments>
		<pubDate>Tue, 31 Jan 2012 17:29:05 +0000</pubDate>
		<dc:creator>tglek</dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://blog.mozilla.com/tglek/?p=557</guid>
		<description><![CDATA[DXR is now uber-fast. See bottom of search pages for timing info. Give it a try. We have a few more bugs to fix before we jump into fixing the UI.]]></description>
			<content:encoded><![CDATA[<p><a href="http://dxr.lanedo.com/index.html">DXR </a>is now <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=722743">uber-fast</a>. See bottom of search pages for timing info. Give it a try. We have a few more bugs to fix before we jump into fixing the UI.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.mozilla.com/tglek/2012/01/31/fast-dxr/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>At hackerspace.be getting ready for FOSDEM</title>
		<link>http://blog.mozilla.com/tglek/2012/01/30/at-hackerspace-be-getting-ready-for-fosdem/</link>
		<comments>http://blog.mozilla.com/tglek/2012/01/30/at-hackerspace-be-getting-ready-for-fosdem/#comments</comments>
		<pubDate>Mon, 30 Jan 2012 11:49:53 +0000</pubDate>
		<dc:creator>tglek</dc:creator>
				<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://blog.mozilla.com/tglek/?p=549</guid>
		<description><![CDATA[We just started our Perf/Snappy workweek in Brussels, Belgium. hackerspace.be let us use their space. If you are also performance hacker in the area, why not drop in for some beers? See Dietrich&#8217;s post for more details.]]></description>
			<content:encoded><![CDATA[<p><img src="http://lh3.googleusercontent.com/-gI4k_kzhP34/TyZ9_NzQi_I/AAAAAAAACgc/nRzbygBz6Jw/s800/IMG_20120130_120734.jpg" alt="&quot;Lubricants&quot;" /></p>
<p>We just started our Perf/Snappy workweek in Brussels, Belgium. <a href="https://hackerspace.be/">hackerspace.be</a> let us use their space. If you are also performance hacker in the area, why not drop in for some beers?</p>
<p>See Dietrich&#8217;s <a href="http://autonome.wordpress.com/2012/01/30/firefox-performance-work-week-fosdem/">post </a>for more details.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.mozilla.com/tglek/2012/01/30/at-hackerspace-be-getting-ready-for-fosdem/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Snappy, January 26</title>
		<link>http://blog.mozilla.com/tglek/2012/01/26/snappy-january-26/</link>
		<comments>http://blog.mozilla.com/tglek/2012/01/26/snappy-january-26/#comments</comments>
		<pubDate>Thu, 26 Jan 2012 23:22:09 +0000</pubDate>
		<dc:creator>tglek</dc:creator>
				<category><![CDATA[snappy]]></category>

		<guid isPermaLink="false">http://blog.mozilla.com/tglek/?p=543</guid>
		<description><![CDATA[Slow Sessions &#8211; Tabs-on-Demand Armed to the teeth with about:jank, I was testing session restore scenarios that people reported. While at it I came up with a testcase for bug 711193. At first we were going to use telemetry to debate the merits of tabs on demand by default, but I feel my example illustrates [...]]]></description>
			<content:encoded><![CDATA[<p><strong>Slow Sessions &#8211; Tabs-on-Demand</strong></p>
<p>Armed to the teeth with <a href="https://addons.mozilla.org/en-US/firefox/addon/aboutjank/">about:jank</a>, I was testing session restore scenarios that people <a href="https://blog.mozilla.com/tglek/2012/01/11/call-for-snappy-help-looking-for-a-lots-of-tabs-sessions-with-lag/">reported</a>. While at it I came up with a <a href="https://plus.google.com/108936502671219351445/posts/UMzBAQr3xDS">testcase</a> for bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=711193">711193</a>. At first we were going to use telemetry to debate the merits of tabs on demand by default, but I feel my example illustrates responsiveness problems with session-restore well enough. Gavin is looking into this so we can make a decision this week.</p>
<p><strong>Laggy </strong><strong>Sessions<br />
</strong></p>
<p>On my machine about:jank indicated that most lag was caused by our direct2d accelerated drawing code, <a title="NEW - d2d causes browser to lag severely, especially in powersave mode" href="https://bugzilla.mozilla.org/show_bug.cgi?id=721273">bug 721273</a>. Turning off graphics acceleration made things a lot less slow (Options/Advanced/use hardware acceleration) . It would be nice if people experiencing lots of lag in their sessions (on youtube, blogs with high quality backgrounds, etc) could try <a href="https://addons.mozilla.org/en-US/firefox/addon/aboutjank/">about:jank</a>. This requires running a very recent nightly.</p>
<p>Install the extension, go to about:jank, browse around, then refresh about:jank. In the case of gfx lag, DrawThebesLayers shows up on top.</p>
<p><strong>Imminent Cycle Collector + GC Improvements<br />
</strong></p>
<p>Olli is landing huge cycle collector improvements (half of the patches landed so far), <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=705582" rel="nofollow">bug 705582</a>, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=717500" rel="nofollow">bug 717500</a>. If that doesn&#8217;t solve all CC problems by Tuesday, Andrew is standing by with bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=710496" target="_blank">710496</a> to limit how often CC can run. If we are lucky, incremental JS GC will land before Tuesday too (bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=641025">641025</a>). Landing by Tuesday means that these improvements have a good chance of showing up in Firefox 12. CC + GC are the most well-known causes of pauses in Firefox, so this is very exciting.</p>
<p><strong>Other stuff</strong><br />
<strong></strong></p>
<p>Profiling tools are moving along at a good clip. Benoit&#8217;s <a href="https://developer.mozilla.org/en/Performance/Profiling_with_the_Built-in_Profiler">profiler</a> works well on Mac now, hopefully Windows support will happen next week. Non-destructive chromehang is <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=712109">almost</a> landed.</p>
<p>Telemetry histograms should now survive restarts (so we can do shutdown telemetry, etc), <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=707320">bug 707320</a>.</p>
<p>Peptest didn&#8217;t manage to survive deployment on try due to <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=719618" rel="nofollow">bug 719618</a>, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=719511" rel="nofollow">719511</a>.</p>
<p>We are now transitioning from identifying issues to fixing identified issues. It&#8217;s exciting to move from speculation as to what sucks to actual results. For more details see <a href="https://wiki.mozilla.org/Performance/Snappy/2012-01-26">meeting notes</a>.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.mozilla.com/tglek/2012/01/26/snappy-january-26/feed/</wfw:commentRss>
		<slash:comments>19</slash:comments>
		</item>
		<item>
		<title>Snappy, January 19: Brought you by Ironic JS</title>
		<link>http://blog.mozilla.com/tglek/2012/01/20/snappy-january-19-brought-you-by-ironic-js/</link>
		<comments>http://blog.mozilla.com/tglek/2012/01/20/snappy-january-19-brought-you-by-ironic-js/#comments</comments>
		<pubDate>Fri, 20 Jan 2012 21:50:54 +0000</pubDate>
		<dc:creator>tglek</dc:creator>
				<category><![CDATA[snappy]]></category>

		<guid isPermaLink="false">http://blog.mozilla.com/tglek/?p=537</guid>
		<description><![CDATA[Meeting notes. Network Cache Horrors Last week we discovered that our cache uses main thread locks to successfully block on off-main thread io. See (Bug 695399, Bug 717761). QA did an experiment which confirmed that our disk cache is performing poorly. Flash Lag We are looking into reports of flash lag, tracking Bug 720000. Initial QA data shows [...]]]></description>
			<content:encoded><![CDATA[<p><a href="https://wiki.mozilla.org/Performance/Snappy/2012-01-19">Meeting notes</a>.</p>
<p><strong>Network Cache Horrors</strong></p>
<p><a href="https://blog.mozilla.com/tglek/2012/01/12/snappy-jan12/">Last week</a> we discovered that our cache uses main thread locks to successfully block on off-main thread io. See (<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=695399">Bug 695399</a>, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=717761">Bug 717761</a>). QA did an <a href="http://groups.google.com/group/mozilla.dev.tech.network/browse_thread/thread/6dfa3e6ebe80c336">experiment</a> which confirmed that our disk cache is performing poorly.</p>
<p><strong>Flash Lag</strong></p>
<p>We are looking into reports of flash lag, tracking <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=720000">Bug 720000</a>. Initial QA data shows a significant slowdown when page is first loaded and smaller slowdowns later. There are also long browser pauses when the flash container progress freezes.</p>
<p><strong>Profiling</strong></p>
<p>Vlad continued work on non-destructive chromehang, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=712109">Bug 712109</a>. Client-side is ready to land and he is wrapping up symbolification for the server-side.</p>
<p><a href="https://developer.mozilla.org/en/Performance/Profiling_with_the_Built-in_Profiler">Interactivity profiler</a> is now able to collect stacks on 64-bit MacOS. Benoit is looking for contributors to add Windows, Linux support (<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=719536">Bug 719536)</a>. I highly encourage adventurous contributors to help out with that as it involves modifying some concise, straightforward, yet highly <a href="https://github.com/bgirard/Gecko-Profiler-Addon/blob/master/lib/symbolicate.js">ironic JavaScript</a>. We are also looking for help with the profiler UI. If you are a skilled addon/frontend person, see <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=719530">Bug 719530</a>.</p>
<p>Jeff posted an early preview of about:jank <a href="http://people.mozilla.com/~jmuizelaar/aboutjank-0.1.xpi">addon</a>. He also working on measuring painting speed via telemetry. Note this addon is buggy and requires a very recent nightly.</p>
<p>Last week I asked for some laggy session restore profiles. I&#8217;m behind on reproducing those(will be done today or next week). I&#8217;ve been in email contact with several of the commenters. I really appreciate the data gathered so far.</p>
<p><strong>Snappy UX</strong></p>
<p>Jared landed smooth scrolling, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=198964">Bug 198964</a>. He is now working on hooking it up to scrolling via scrollbar, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=710373">Bug 710373</a>. Up next: fixing fallout from turning on smooth scrolling, hooking it up to the refresh driver and tweaking scrolling physics.</p>
<p>Marco landed inline autocomplete, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=566489">Bug 566489</a> and is now fixing fallout from that too.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.mozilla.com/tglek/2012/01/20/snappy-january-19-brought-you-by-ironic-js/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Snappy Jan12</title>
		<link>http://blog.mozilla.com/tglek/2012/01/12/snappy-jan12/</link>
		<comments>http://blog.mozilla.com/tglek/2012/01/12/snappy-jan12/#comments</comments>
		<pubDate>Thu, 12 Jan 2012 23:21:03 +0000</pubDate>
		<dc:creator>tglek</dc:creator>
				<category><![CDATA[snappy]]></category>

		<guid isPermaLink="false">http://blog.mozilla.com/tglek/?p=535</guid>
		<description><![CDATA[The most user facing fix has been discovery and removal of some sneaky cache IO on the main thread. Saptashi did some analysis on the impact of running sqlite in async mode on mobile. Turns out it&#8217;s only a win for DELETEs. Expect a blog post from him soon. Dave discovered that we sometimes wait [...]]]></description>
			<content:encoded><![CDATA[<p>The most user facing fix has been <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=715774">discovery</a> and <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=716293">removal</a> of some sneaky cache IO on the main thread.</p>
<p>Saptashi did some analysis on the impact of running sqlite in async mode on mobile. Turns out it&#8217;s only a win for DELETEs. Expect a blog post from him soon.</p>
<p>Dave <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=715774#c3">discovered</a> that we sometimes wait on locks on the main thread.</p>
<p>Jeff and Bas are looking into diagnosing when d2d causes a slowdown.</p>
<p>There was discussion of 4x reduction in cycle collection times landing soon, focusing on having cycle collector run less, etc. Lots of work(chromehang, profiler, &#8230;) is continuing from last week.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.mozilla.com/tglek/2012/01/12/snappy-jan12/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Call for Snappy Help: Looking for a lots-of-tabs sessions with lag</title>
		<link>http://blog.mozilla.com/tglek/2012/01/11/call-for-snappy-help-looking-for-a-lots-of-tabs-sessions-with-lag/</link>
		<comments>http://blog.mozilla.com/tglek/2012/01/11/call-for-snappy-help-looking-for-a-lots-of-tabs-sessions-with-lag/#comments</comments>
		<pubDate>Wed, 11 Jan 2012 18:59:02 +0000</pubDate>
		<dc:creator>tglek</dc:creator>
				<category><![CDATA[snappy]]></category>

		<guid isPermaLink="false">http://blog.mozilla.com/tglek/?p=533</guid>
		<description><![CDATA[I have been working under assumption that the browser gets less snappy as more tabs are opened. This increases the chances of having an ill-behaved website in the background. An ill-behaved tab (or a couple of them) can in theory ruin scrolling, typing, clicking, etc in active tabs. However I do not have anything behind [...]]]></description>
			<content:encoded><![CDATA[<p>I have been working under assumption that the browser gets less snappy as more tabs are opened. This increases the chances of having an ill-behaved website in the background. An ill-behaved tab (or a couple of them) can in theory ruin scrolling, typing, clicking, etc in active tabs. However I do not have anything behind anecdotal evidence on this. There are bugs on specific websites in bugzilla, but it would be nice to get them mixed into a realistic set of tabs.</p>
<p>Would someone be willing to contribute a list of webpages they use often that cause Firefox to lag (maybe a session restore file?)? I am a low-tab person myself, so I can&#8217;t easily reproduce this. Please make sure that Firefox is slow with your list of tabs even when all addons are disabled, include a description of slowness encountered.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.mozilla.com/tglek/2012/01/11/call-for-snappy-help-looking-for-a-lots-of-tabs-sessions-with-lag/feed/</wfw:commentRss>
		<slash:comments>32</slash:comments>
		</item>
		<item>
		<title>Snappy, Jan 5</title>
		<link>http://blog.mozilla.com/tglek/2012/01/05/snappy-jan-5/</link>
		<comments>http://blog.mozilla.com/tglek/2012/01/05/snappy-jan-5/#comments</comments>
		<pubDate>Thu, 05 Jan 2012 22:07:36 +0000</pubDate>
		<dc:creator>tglek</dc:creator>
				<category><![CDATA[snappy]]></category>

		<guid isPermaLink="false">http://blog.mozilla.com/tglek/?p=528</guid>
		<description><![CDATA[I expected to a slow week, but there was a surprising amount of progress. I  take this as further evidence that having managers  go on vacation does wonders to engineer productivity Interactivity with lots of tabs We spent a lot of time pondering how to approach browser sluggishness in light of having tons of tabs [...]]]></description>
			<content:encoded><![CDATA[<p>I expected to a slow week, but there was a surprising amount of progress. I  take this as further evidence that having managers  go on vacation does wonders to engineer productivity <img src='http://blog.mozilla.com/tglek/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p><strong>Interactivity with lots of tabs</strong></p>
<p>We spent a lot of time pondering how to approach browser sluggishness in light of having tons of tabs open. On one hand people should understand, that one can&#8217;t expect the browser perform the same whether 1 tab is active or infinity. On the other hand we should do more to a) make the browser punish background tab hogs and b) communicate hogs to the user.</p>
<p>For now we will look at throttling background setTimeouts better (bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=715376">715376</a>, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=715378">715378</a>, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=715380">715380</a>), XMLHttpRequest loops, etc more aggressively. We also plan to make more use of interactive state so Firefox can suspend non-critical tasks (bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=712478">712478</a>).</p>
<p>Occasionally the cycle collector misbehaves, Andrew will look into not running cycle collection frequently when it is slow: bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=710496">710496</a>. Olli has been fixing many of the cycle-collection extremes, I don&#8217;t have bug #s for that, but apparently the improvements are dramatic.</p>
<p><strong>Super-Slow Startups</strong></p>
<p>Thanks to telemetry we now know that some users experience tragic startup speeds ranging from 30seconds to 34hours (bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=701872">701872</a>). Our network cache is to blame for some of these (bug <span class="author-g-l7d8do8q98aujqa9 url"><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=707436">707436</a></span>). Another theory is that an unfortunate turn of events causes us to start loading webpages before the UI is shown (bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=715402">715402</a>).</p>
<p>Vlad will post some of his analysis and interested people can help us with telemetry forensics.</p>
<p><strong>Profiling</strong></p>
<p>Being able to profile interactivity bugs is an important key to making the browser snappier. Large parts of Benoit&#8217;s <a href="https://developer.mozilla.org/en/Performance/Profiling_with_the_Built-in_Profiler">interactivity profiler</a> have landed (bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=713227">713227</a>). Using this <a href=" https://builder.addons.mozilla.org/addon/1023834/latest/">extension</a> on nightly win/mac should give you an idea of what it will look like when completed.</p>
<p>We make heavy use of compiler optimizations. Unfortunately one of them is to omit the stack pointer. Ehsan has setup a developer-friendly <a href="http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/3389798e5ef9744b#">profiling branch</a>.</p>
<p>Vlad is making progress on non-destructive chromehang(bug <span class="author-g-jimvuyh59nuq8hc1 url"><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=712109">712109</a>)</span>. Traditionally we could not do this, but with a combination of telemetry + cycling Ehsan&#8217;s shiny new profiling branch on nightly channel&#8230; we&#8217;ll be in developer heaven.</p>
<p><strong>Responsiveness testing</strong></p>
<p><a href="https://wiki.mozilla.org/Auto-tools/Projects/peptest">Peptest</a> should be landing on try soon, Aki is wrapping stuff up. This should enable us to catch responsiveness regressions on our infrastructure.</p>
<p><strong>Smooth Scrolling</strong></p>
<p>Jared is almost done fixing tests to land smooth scrolling to gather feedback and move on to fancy physics (bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=710372">710372</a>).</p>
<p>Other ongoing projects with nothing specific to link to: Vlad&#8217;s slow-sql telemetry, Rafael&#8217;s quest to close sql connections so we can exit(0), QA browser-cache-effectiveness comparisons.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.mozilla.com/tglek/2012/01/05/snappy-jan-5/feed/</wfw:commentRss>
		<slash:comments>31</slash:comments>
		</item>
	</channel>
</rss>

