Immediately-Invoked Function Expression (IIFE)

Scope in Javascript is function-bound, meaning variables defined in a function are visible inside the same function, and each time a function is invoked it creates a new execution context. This is different from C which confines life span of variables inside a block. For following code:

var a = 1;

function f1() {
  var b = 2;
  console.log('inside f1 a:'+a);
}

function f2() {
  var c = 3;
  return function(d) {
    return d+c;
  }
}

{
var e = 5;
}

f1();

console.log(a);
console.log(b); //error
console.log(e);
console.log(f2()(4)); //closure

Only hidden variable to the global context is b. Since every C function is defined using block Javascript is more loose in the sense that blocks without function declaration doesn’t really do much.

Now move on to Immediately-Invoked Function Expression: the motive behind this is you want to execute a piece of code without contaminating the global context while being able to use many of the global variables. You do it by creating an anonymous function and immediately invoking it:

(function () {
 ...
})();

This is a very common pattern for Javascript and is seen everywhere, especially for locking in the value of
execution context. More reading can be found at http://benalman.com/news/2010/11/immediately-invoked-function-expression/

EMFILE error in node.js

This usually happens when we asynchronously operate on a large number of files in Node.js and due to the async nature of Node.js many files are open at the same time. See explanation at https://stackoverflow.com/questions/16200497/emfile-error-in-async-file-reading

Two solutions: 1) use sync version of readFile. so each file is closed before proceeding to next 2) use callback function for reading next file, something like

function readFile(files, i) {
  if(i>=files.length) return;
  fs.readFile(path+'/'+files[i], 'utf8', function (err,data) {
    if (err) {
      return console.log(err);
    }
    parse(data, function(result){
      readFile(files,i+1);
    });
  });
}

fs.readdir(path, function(err, files) {
  readFile(files,0);
});

useful javascript libs

http://underscorejs.org/

to be updated

python sqlite3 vs. node-sqlite3: performance test

I am recently learning node.js and trying to duplicate a small website from flask/python to Node.js. Due to memory constraint I ended up with using SQLite as my production database – although it says never to use SQLite for production XD.

One thing I noticed is that node-sqlite3 (the most active module from Node.js community for SQLite access) seems to a little bit sluggish compared to python, especially when doing pagination. Really? Everything in Node.js is async and shouldn’t it be more responsive? Baffled and curious, I did follow comparison: do multiple SELECT on a small database file (223 megabyes) and time it. Below is my code for each:

Node.js

var sqlite3 = require('sqlite3').verbose();
var util=require('util');
var dbfn = './db.sqlite';

var db = new sqlite3.Database(dbfn,sqlite3.OPEN_READONLY, function(err) {
  if(err) {
    console.log(err);
  } else {
    var perpage=10,max=500,table='data2012',kw='sa';
    for(var offset=1;offset<max;offset+=perpage) {
      stmt = util.format('select * from %s where xxx like "%s%" limit %d offset %d',table, kw,  perpage, offset);
      db.all(stmt);
   }
 }
});

Python:

import sqlite3
DATABASE = './db.sqlite'
db=None
try:
  db = sqlite3.connect(DATABASE)
except:
  sys.stderr.write(os.getcwd())

table='data2011'
kw=('sa%',)
perpage=10
max=500
for offset in xrange(1,max,perpage):
  stmt = 'select * from %s where xxx like ? limit %d offset %d'%(table, perpage, offset)
  rs = db.execute(stmt, kw)
  rs.fetchall()
db.close()

Ignore the table/columns the point is that it has more than enough data to complete the loop. Each was run 3 times and here’s the average:

• Node-sqlite3: 2.945s
• Python 1.542s

Looks like Python module is a lot faster. To eliminate any possible uncertainty I increased the loop# to be 1000. Again I ran each for 3 times for an average:

• Node-sqlite3: 10.085s
• Python: 6.040s

Python is still faster, but the gap is shrinking. How about 3000 iterations?

• Node-sqlite3:1m5s
• Python: 56.154s

5000?

• Node-sqlite3: 2m23s
• Python: 2m28s

So the observation so far is that python-sqlite3 beats node-sqlite3 when offset is small (remember sqlite doesn’t really support offset; it reads off all the data and discard  unneeded ones). When offset is getting large, both are getting equally slow. Maybe Node.js overall has a higher throughput its sqlite3 module is less satisfying, at least as of today.

BTW, one trick to optimize Sqlite access performance is to VACUUM the database. This made huge  difference on my database  file.

Coding in the node.js way

First of all node.js is about asynchronousness. So instead of writing up your functions one by one, all lined up with same indentation which are supposed to execute sequentially, with node.js, after a while I found myself to soon jump around method definitions, and inevitably embed functions with deeper and deeper indentation…

It’s getting funny.

to be updated.

exports and module.exports in node.js

to export multiple properties (function, variables), use exports.property = xxx.

to export the whole module as one object or class (constructor function), use module.exports = your_class

see http://www.hacksparrow.com/node-js-exports-vs-module-exports.html

node.js backward compatibility with node-sqlite3

Node.js is so radically evolving that there’s many compatibility issues such that packages that used to work now simply fail. E.g. node-sqlite3 stopped working (the sample code on its homepage says ‘segfault’ under node 0.10.x). Fortunately after complaining on its github I saw it got fixed quickly: https://github.com/developmentseed/node-sqlite3/commit/25db957806ae651dcd31292c6b932c379cfd2662 . I don’t use boost so I am not sure how that is related.

An alternative is to use node 0.8.x.