#version 1 - 'functional'
cur_period = Time.now.month - 1
RecurringActivation.find(:all, :select => "product_id, period").select { |r|
  cur_period % r.period == 0
}.map &:product_id

#version 2 - 'imperative'
cur_period = Time.now.month - 1
result = []
RecurringActivation.find(:all, :select => "product_id, period").each { |r|
  result << r.product_id  if cur_period % r.period == 0
}

In the first version I compose functions (methods) ‘select’ and ‘map’: the blocks have no side-effects, and this is why I call it ‘functional.’ This is shorter and more clear. Of course, this is implemented by the library using iteration and imperative assignment, but at least my code feels functional.

In the second version I use ‘each’ with a block that does both filtering and ‘mapping’ in one step: I add the product_id explicitly to the products array for each object which satisfies my criterion.

Notice that the first version first produces a complete filtered list which is then passed on to the map method which produces a complete mapped and filtered list: the list is iterated twice, and an intermediate array containing only the filtered objects exists in memory and is later collected as garbage. In the second version the list is only iterated once, and such an intermediate array of filtered objects is never allocated. Hence one might choose the latter for performance reasons.

Now consider the same in Clojure or any lazy functional language. We might have (no active record here):

krukow:~/Projects/private/okooko-prod/tmp$ cl
Clojure
user=> (def recurring_activations '({:product_id 1 :period 2}
                                    {:product_id 2 :period 3}
				    {:product_id 3 :period 2}))
#'user/recurring_activations
user=> (def res
         (map #(do (println "map") (:product_id %))
             (filter #(do (println "filter") (= 0 (mod (:period %) 2)))
                 recurring_activations)))
#'user/res
user=>

Nothing has been mapped or filtered yet since Clojure is fully lazy. So res is now a lazy seq which will compute exactly what is needed on demand. Now think about what will happen if I just peek at the first element of res… In a non-lazy language, already the entire recurring_activations list would have been filtered (printing “filter” three times), then that result would have been mapped (printing “map” twice) and finally the first element would be looked up. So the output would be
“filter”
“filter”
“filter”
“map”
“map”
(return first element of list).

What happens in Clojure? It prints “filter” “map” and gives the first element:

user=> (first res)
filter
map
1
user=>

In effect we don’t need an intermediate list containing the filtered elements which is then garbage collected. Notice also that if we just look at the entire list (recomputing res first) we get:

user=> res
(filter
map
filter
filter
map
1 3)
user=>

So the side effects are evaluated in a different order than had we realized the entire filtered list first. This can be counter intuitive when one is used to eager languages (which all mainstream languages are); however, once understood laziness can be extremely powerful and elegant.

In effect, in lazy languages we can compose functions that work on entire sequences, e.g., map and filter, to obtain a lazy sequence which evaluates the all of the composed functions on each element in sequence.

If that sounded abstract and poorly phrased, I can try to say it more concretely: In Ruby (or Java) I would need to write a new function: filter_and_map taking two “blocks”/”procs” and a list, then using e.g. “each” on the list and apply first the filter “proc” then the map “proc” — the existing functions “map” and “select” can’t help me. In Clojure (or Haskell) I can simply compose the existing library functions filter and map to obtain the same thing:

(def filter_map
	(comp (partial map :product_id)
	          (partial filter #(= 0 (mod (:period %) 2)))))

or just use it inline

user=> (def res
	(map :product_id
	 (filter #(= 0 (mod (:period %) 2)) recurring_activations)))
#'user/res
user=> res
(1 3)
user=>

function object(p) {
   function F(){}
   F.prototype = p;
   return new F();
}

The object function creates a new object which has the input object (p) as it’s prototype.

On the comp.lang.javascript newsgroup Richard Cornford showed a functionally equivalent version which has better performance in general:

var object = (function(){
    function F(){}
    return function(p){
        F.prototype = p;
        return new F();
    };
})();

In this version, all invocations of object share the same F which has its prototype mutated with each call. Cornford argues:

[The first version of 'object']... is an example of the process that clearly expresses what is being done, but is not particularly efficient as it creates a new - F - function each time it is executed, but all of those - F - functions are essentially identical. If this is to be done often then a more efficient approach would be to only create a single - F - function and put it where it could not be modified by external code.

Now, it is important to notice that in general one has to be careful when applying this technique to recursive functions as a variable mutation in one level of recursion may affect others. Also, if we were to put threads into JavaScript, this code would go from being thread-safe in the original form to non-thread safe in the optimized form. However, for now, this technique can be applied in performance-critical functions.

In fact, there is a general technique here that one might call code specialization via higher-order functions (which can be seen as a poor-mans form of partial evaluation). Here is a simple example of that general technique: The ‘mk_tag’ function creates the string for an html tag with a class attribute and a text-contents.

function mk_tag(tag_name,clazz,contents) {
   return '<'+tag_name+' class="'+clazz+'">'+contents+'</'+tag_name+'>';
}

Using code specialization via higher-order functions (by currying), we can make specialized functions for writing e.g. ‘div’ tags, and specialized (faster) functions for making ‘div’ tags with certain classes. The trick is to compute as much as is possible with the given inputs before returning the specialized function:

//a curried version which specializes to it's input
function curried_mk_tag(tag_name) {
  var tag_hd = '<'+tag_name+' class="',
      tag_tail = '</'+tag_name+'>';
  return function(clazz) {
     var head = tag_hd+clazz+'">';
     return function(contents) {
         return head+contents+tag_tail;
     };
  };
}

var mk_div = curried_mk_tag("div");
var mk_div_green = mk_div("green");
var mk_div_blue = mk_div("blue");
mk_div_green("karl")//<-- "<div class="green">karl</div>"
mk_div_blue("karl")//<-- "<div class="blue">karl</div>"

This is elegant as functions can be reused, e.g., ‘mk_div_green(“karl”);mk_div_green(“krukow”)’. But notice that it is more efficient than simply using a general currier (e.g., Diaz); essentially it is a form of manual partial evaluation.

I’ll post some performance measurements in a later posting, but initial results show that we can reduce execution time by roughly 40% by using the sharing form of the object function.

More Examples

I’m not sure how many JavaScript programmers are familiar with this type of optimization. Here are a bunch of real-world examples where it can be applied:

Prototype – Ajax.request function

var Ajax = {//original
  getTransport: function() {
    return Try.these(
      function() {return new XMLHttpRequest()},
      function() {return new ActiveXObject('Msxml2.XMLHTTP')},
      function() {return new ActiveXObject('Microsoft.XMLHTTP')}
    ) || false;  },

  activeRequestCount: 0
};

The thing to notice here is that every time getTransport is called prototype will recompute which XMLHttp transport to use. However, the result of Try.these will always be the same in a particular run of Prototype, i.e., the showing of a page in one browser. So we might as well precompute which object is the correct one:

var Ajax = {//modified form
  getTransport: Try.these(
         function() { new XMLHttpRequest(); //test if it exists
            return function() {return new XMLHttpRequest();}
         },
         function() { new ActiveXObject('Msxml2.XMLHTTP'); //test
            return function() {return new ActiveXObject('Msxml2.XMLHTTP'); }
         },
         function() { new ActiveXObject('Microsoft.XMLHTTP');
            return function() {return new ActiveXObject('Microsoft.XMLHTTP'); }
         }),

  activeRequestCount: 0
};

jQuery - attr function

attr: function( name, value, type ) {
 var options = name;

 // Look for the case where we're accessing a style value
 if ( name.constructor == String )
  if ( value === undefined )
   return this[0] && jQuery[ type || "attr" ]( this[0], name );

  else {
   options = {};
   options[ name ] = value;
  }

  // Check to see if we're setting style values
 return this.each(function(i){
  // Set all the styles
  for ( name in options )
   jQuery.attr(    type ?  this.style :     this,
    name, jQuery.prop( this, options[ name ], type, i, name )   );
 });
}

With jQuery we can’t write a curried form as that would break compatability. However, we can still perform optimizations like what we had with the ‘object’ function. Notice that the function supplied to ‘each’ is created with each invocation of ‘attr’, you can also see a for-loop where a check to ‘type’ is made with each iteration. In our optimized version, attr chooses which inner function to give to ‘each’ by checking type first.

jQuery.fn.attr = (function(){
    var type,
        options,
        inner_type = function(i){
          // Set all the styles
          var t  = type,
              s  = this.style;
          for (var name in options ) {
              jQuery.attr(s,
                          name,
                           jQuery.prop( this, options[ name ], t, i, name )
              );
          }
        },
        inner_no_type = function(i) {
          for (var name in options ) {
              jQuery.attr(this,
                          name,
                           jQuery.prop( this, options[ name ], null, i, name )
              );
          }
        };

    return function( name, value, t ) {
                type = t;
                options = name;
  // Look for the case where we're accessing a style value
  if ( name.constructor == String )
   if ( value === undefined )
    return this[0] && jQuery[ type || "attr" ]( this[0], name );

   else {
    options = {};
    options[ name ] = value;
   }

  // Check to see if we're setting style values
  return this.each(t ? inner_type : inner_no_type);
 };
})();