Optimization

Installing xhprof on XAMPP for OSX Lion

 

Directions adapted from Ben Buckman.

Download xhprof.

cd path/to/xhprof/.../extension

# If you don't have autoconf... I didn't.
sudo chmod o+w /usr/local/bin  #(brew needs to write a symlink there)
brew install autoconf

sudo /Applications/XAMPP/xamppfiles/bin/phpize

Make sure you have a CLI C compiler. I installed one via XCode.

sudo MACOSX_DEPLOYMENT_TARGET=10.6 CFLAGS='-O3 -fno-common -arch i386 -arch x86_64' LDFLAGS='-O3 -arch i386 -arch x86_64' CXXFLAGS='-O3 -fno-common -arch i386 -arch x86_64' ./configure --with-php-config=/Applications/XAMPP/xamppfiles/bin/php-config-5.3.1

sudo make

sudo make install

sudo nano /Applications/XAMPP/xamppfiles/etc/php.ini

Add these lines to php.ini:

[xhprof]
extension = xhprof.so
xhprof.output_dir = "/Applications/XAMPP/xhprof-logs"

Restart Apache.

My Moodle Page, Now With 99.6% Fewer Queries

 

My work recently upgraded from Moodle 1.9 to 2.3, and some users were experiencing slow page loads while the site was zippy for others. Today we discovered that, for some users, the My Moodle dashboard page was requiring several thousands of DB queries. For one user, enrolled in four courses, the page required over 14,000 queries. I guess it could be worse: one user reported over 95,000!

This was completely unacceptable; this page is a common navigation point for all users, and every user is forwarded there on login.

With xdebug and Autosalvage rocking, it only took me about three hours to rework the page so that only the course links are displayed by default, and a button is provided beside each to load that course’s activities into the page via Ajax. Since most users just use the page for navigation between courses, this tradeoff seems well worth the performance gain. Now this page–without displaying activities–is down to ~60 queries for every user (sadly average for a Moodle page).

I suspect that loading the activity list for a large course will still take a performance bite, but in my limited testing it seemed pretty instantaneous–yes, there’s a reason why modern apps are built on Ajax. Although good work has been done to cache front-end files, Moodle still seems to be in serious need of query reduction optimization when building HTML pages.

After getting some feedback over the weekend, I’ll release this patch for other Moodle providers. Our theme uses jQuery and the Javascript side of this was maybe 10 lines, but I imagine it would need to be ported to YUI to get into core.

Closure Compiler is smarter than you

 

I’ve known about Google’s Javascript minifier, Closure Compiler, for awhile, but after sending a couple snippets through it today I realized it’s a pretty impressive piece of work.

Input:

function howManyMatch(arr, pattern) {
   var l = arr.length;
   var total = 0;
   var i = 0;
   for (; i < l; i++) {
       if (pattern.test(arr[i])) {
           total++;
       }
   }
   return total;
}

Output: 

function howManyMatch(b,d){for(var e=b.length,c=0,a=0;a<e;a++)d.test(b[a])&&c++;return c};

Or with whitespace re-added:

function howManyMatch(b, d) {
    for (var e = b.length, c = 0, a = 0; a < e; a++)
        d.test(b[a]) && c++;
    return c
}

Optimizations:

  • shortened parameter names and removed unneeded semicolons (YUI Compressor already did this much)
  • combined multiple var statements into one declaration
  • moved that declaration into the first section of the for loop (to save one semicolon!)
  • removed brackets around blocks with only one statement
  • replaced if statement with && operator (to save two bytes)

Several of these are often done by JS devs by hand. With closure compiler on tap, we no longer have to. Just concentrate on readability and maintainability and let CC worry about size optimization.