Category Archives: programming

tick, tock… Time waits for No One

Ok so what I am about to discuss might be old news for most but for me it’s new. After discovering this I have to admit that I am a bit disappointed in myself for not already knowing this.

When implementing asynchronous methods in Node I had always done the following:

function asynchProcessFunc = function(callback) {
    setTimeout(function(callback){
        // process the request now
        callback(returnData);
    }, 0);

    // return back 
};

It was recommended by someone that I change this out for the process.nextTick(cb) method. Being a firmware developer in previous lifetimes the pure mention of tick had me intrigued.

Was it actually processing CPU ticks?

Turns out the answer was No but still what I did find was something far better than a zero based timeout. I had always known that setTimeout(cb, timer) with a zero based timer was never going to be accurate but I had decided it was the best I could ever get.

To get an idea of a difference between the two I wrote the following to measure setTimeout:

setTimeout(function(){
    var startTime = process.hrtime();

    setTimeout(function() {
        var timeDiff = process.hrtime(startTime);
        console.log('setTimeout time diff - ', timeDiff[0]*1e9 + timeDiff[1], '(nanoSecs)');
    }, 0);
}, 1000);

I rounded the average rate to 1600000.

I then changed the program to use process.nextTick() like the following:

setTimeout(function(){
    var startTime = process.hrtime();

    process.nextTick(function() {
        var timeDiff = process.hrtime(startTime);
        console.log('nextTick time diff - ', timeDiff[0]*1e9 + timeDiff[1], '(nanoSecs)');
    });	
}, 1000);

I rounded the average rate to 400000, which gives me a difference of about 4x performance increase. Depending on your product this I am sure will change but even the improvement comes in at 2x that is still a major performance increase.

Happy coding everyone.

Sometimes sanity isn’t the best route

I saw the following post on twitter earlier this week:

tweet

I have to admit that my first response was of course all the time. Then afterwards it got me thinking about those times that I broke this rule.

Don’t look at me or tell me that you have never patched bad code.

We all have worked somewhere where there was this one class, function or piece of code that we dreaded working on and when we did it was precision strike. You know the drill:

Get in, get out and leave no trace behind that says you were there.

I worked this one job where a large part of what our software did was track the status that certain types of documents could be in. There was myself and a few other programmers that were aware of the process and rules for how these documents changed status and we always hated when customers or program managers wanted to “tweak” those rules.

We often talked about rewriting all that code and in some projects we actually attempted to schedule time for its work. In reality though it was the largest plate of spaghetti most of us had ever seen and each time we opted against it. Usually our excuse for not doing was always the same:

“If it ain’t broke, don’t fix it.”

If you google that phrase you will find hits all over the place about. So which famous engineer do we choose to associate this saying to? Amazingly this quote belongs to a business man by the name of Bert Lance who at the time was working for President Carter.

Please don’t take this to mean that I am supporting this type of thinking all the time. The whole idea of taking things that are “working” and changing them is a business model (disruptive technology) for so many of todays majorly successful companies.

Maybe for fun though I will tweet the following:

One of the quickest ways to break something is to fix it when it ain’t broken.

Later everyone and as usual happy coding!!!   =)