benchmark

hey I wanted to communicate some of my findings before I get heavily involved with ads again.

I built a component called 'boxlet' that resizes itself on click. You can build the component yourself -its included with beast. Boxlet grows taller and shorter when it is clicked, just link the ribbon ad. I replaced the ribbon ad with boxlet and did some analysis -I activated profiling in firefox, expanded then and minimized boxlet then stopped the profiler.

• screenshot-disabled-nothing.png
  • json
• screenshot-disabled-foxbox.png
  • json
• screenshot-disabled-picturefillfsnavigation.png
• screenshot-disabled-picturefillfsnavigationsecondarynav.png
  • json
• screenshot-added-throttling.png

My machine: 2.3GHz, Core i7, 8GB DDR3

In both firefox and chrome there is great lag/choppiness. If we comment out the body of ads.bindEvents (binding ads.ribbonResized to events), we can open and shut boxlet with no lag or choppiness.

The profiler indicated that most of the activity comes from these:

main_sync/source/FSNavigation.js
main_async/source/app/views/viewSecondaryNav.js
main_sync/source/picturefill.js

I commented out window resize listeners in these scripts and the performance issues went away completely. In this situation, Firefox's developer tools used more resources than boxlet or ribbonResized. I included screenshots of the profiling activity.

The current bottle necks could use standard improvements. throttled function calls, memoized data. Additionally, we would likely benefit from centralization of our window listeners. Its common to have one script add a listener and have other scripts hook into that which is more performant but also makes debugging easier as you can ignore all resize subscriber but one -or ignore one subscriber and call the others.

I found many listeners on window resize with grep in foxsports-core-ui/src:

• window\)\.resize 16
• window\.resize 7
• window\)\.scroll 26
• window\.scroll 20

60 possible listeners functions are independently bound to window resize. Two or three resize/scroll listeners would be more reasonable. Most of the current listeners are unthrottled (resize will many times unnecessarily in short time).

These scripts seem to be the primary affectors of layout:

• ads.js
• contentScroll.js
• msnHeader.js
• pinColumnBOnScroll.js
• pinOnScroll.js
• FSNavigations.js

Other things I noticed...

ads.js

$('.belowNav').bind('resize', Ads.ribbonResized);

What's interesting is that there is no 'resize' event published on elements. Binding to this 'event' is an unnecessary and expensive abstraction from jquery. The 'ribbonResized' method constructs big jqeury objects each time it is called.

I began this to find performance issues around layout. Modifying the layout will not give us a great performance boost at this time but would still be worth consideration as a future improvement. There is much additional scripting and complexity around layout that could be removed, for example this:

viewSecondaryNav

$(window).on("resize", function() {
    showIn2N3Col();
});

FSNavigation

me.determineListItems();
me.determineColumnView();

ads

$sectionSidebarEl.css('margin-top', (newMargin < 70 ? '' : newMargin+ 'px'));