Date reconverter

This is the date reconversion utility that I mentioned in a previous post. It takes similar arguments to the string.toDate() extension posted being in format dmy to represent day/month/year with this one having the optional argument t to denote the time. double a character means the result will be padded (so if the month is april using m will return 4 but mm will return 04). Pretty self explanatory, but I like the slickness of it. It could be better improved to organise times being formatted before dates, maybe something to consider at a later date.

/* Convert a date into a string.
* The format argument denotes the format (including padding zeros) the
* date is returned as. d - day, m - month, y - year, t - time.
* Double characters or quad y for year) will pad/extend that number.
* Optional: argument d_l is the date delimiter, t_l is the time delimiter.
* @param (String) format
* @param (String) d_l (Optional)
* @param (String) t_l (Optional)
*/
Date.prototype.convert = function(format, d_l, t_l) {
    var d_l = d_l || "/",
        t_l = t_l || ":",
        date = [],
        pad,
        d = this;
        
    pad = function(n) {
        return (n < 10) ? String("0"+ n) : n;
    }
    
    format = format.replace(/(m+)|(d+)|(y+)|(t+)/gi, function(s) {
        switch(s) {
            case "d": date.push(d.getDate()); break;
            case "dd": date.push(pad(d.getDate())); break;
            case "m": date.push(d.getMonth()); break;
            case "mm": date.push(pad(d.getMonth())); break;
            case "y": date.push(String(d.getFullYear()).substring(2, 4)); break;
            case "yy": date.push(String(d.getFullYear()).substring(2, 4)); break;
            case "yyyy": date.push(d.getFullYear()); break;
            case "t": date.push(d.getHours()+ t_l + d.getMinutes()); break;
            case "tt": date.push(pad(d.getHours()) + t_l + pad(d.getMinutes())); break;
        }
    });
    
    return (date.length < 3)
        ? null : (date.length == 3)
            ? date.join(d_l)
            : date[0]+d_l+date[1]+d_l+date[2]+" "+date[3];
}


// Usage:
var strDate = "4::13::1976 10.30";

// the previous post String extension to create a date object
var objDate = strDate.toDate("mdy");

// Use this date convert extension
var newStrDate = objDate.convert("ddmmyytt", ".", ":"); // outputs 13.04.76 10:30

Garbage Collection

Thought I'd post up a bit I wrote at work discussing differences in memory handling and garbage collection in different browsers.

Background
Microsoft's implementation of ECMAScript is actually called JScript (not JavaScript), and it's behaviour with regards to garbage collection differs from the original implementation of JavaScript in SpiderMonkey (SpiderMonkey is the name for the first JavaScript engine written by Netscape, Firefox is based on this engine). It's worth noting that the JScript/JavaScript engine does not itself provide a host environment for the DOM - they are two separate structures that exist together, but can logically exist apart.

The main difference
IE uses non-generational mark and sweep garbage collection versus SpiderMonkey's generational mark and sweep garbage collection. The "mark and sweep" bit means that each object (either JScript or JavaScript) has an attribute that is set to 1 if it is to be collected and 0 if it is not. As the generational/non-generational bit of the name implies, what it means is that SpiderMonkey will find older objects first and clean them out (generational), whereas IE will do this fairly indiscrimately and just find JScript objects in memory and check to see whether to garbage collect them (non-generational). Simply put SpiderMonkey will push the objects to be collected to the bottom of the memory heap (http://en.wikipedia.org/wiki/Heap_(programming)) and then knows to grab the bottom of the pile to free memory, whereas JScript will throw objects (relatively) randomly onto the heap and then pick through all of them individually checking to see if that object needs collecting. As you can imagine there's an impressive performance lean towards generational garbage collection.

Implications
Because of the relationship between the DOM and the JScript/JavaScript engine, stacking objects in memory becomes very important. As you can imagine, keeping less objects in memory now has real performace implication in IE - especially circular references between the engine and the DOM such as an array of nodes - an example of this problem would be memory leaking through event handlers in the DOM (http://www.jibbering.com/faq/faq_notes/closures.html#clMem) - in fact this problem surfaces with any sort of large numbers of data types/objects held in memory at one time. It also should promote forced memory handling when resources can become free, rather than simply waiting for automatic garbage collection to be initiated (statements such as "myArray = myString = myNumber = null") to make sure the object has the least memory allocated to it after use and the automatic garbage collection then becomes much quicker.

Links to more info
Garbage collection: Wikipedia Garbage Collection
SpiderMonkey: Wikipedia SpiderMonkey
Garbage collection models: North Eastern University