如何使用Node.js的原生Addons提升性能(译)
原文：How to get a performance boost using Node.js native addons
也许你已经听说过上千次，但我今天要向你展示什么是Node.js的原生模块，以及你为什么应该关注它们。
Node.js addons是使用C或C++编写的动态链接共享对象，可以使用require()方法加载，并且像其他普通的Node.js模块一样使用。
(译注：addons: 扩展，为保持统一叫法，不予翻译)
说得这么好听，但是，为什么要我写C++代码，JavaScript已经让我很爽了，并且上一次看到C++代码还是在大学...答案没有别的只有性能！
一个实际的例子
比如，我们要创建一个在线的回文计算器工具，感谢Javascript这门高层次的语言，你很快就想到了一个干净利落的解决方案：
function isPalindrome(str) {
return str === str.split('').reverse().join('');
}
简直就是天才？你迅速发布代码到生产环境，睡觉...但是几天后，你意识到这算法并没有看起来那么好，它实际上特别慢，于是你开始探索新的视野...
Node addons的生态系统
我们需要使用下面的工具来创建addon：
- node-gyp：用于编译原生addons的跨平台命令行接口。
- node-bindings：用于加载原生addon的
.node文件的帮助模块。 - nan：使addon跨Node版本开发更简单。
全部安装：
> npm i node-gyp -g && npm i bindings nan --save
稍等片刻，我们添加"gypfile": true到package(译注：指添加到package.json文件)，并创建一个新binding.gyp文件：
{
"targets": [
{
"target_name": "palindrome",
"sources": [ "palindrome.cc" ],
"include_dirs": [ "<!(node -e \"require('nan')\")" ]
}
]
}
准备就绪，现在用C++写我们的回文方法，代码如下：
#include <nan.h>
using namespace v8;
void IsPalindrome(const FunctionCallbackInfo<Value>& info) {
String::Utf8Value sentence(info[0]->ToString());
std::string str = std::string(*sentence);
int len = str.length();
int half = len / 2;
int start = 0;
int end = len - 1;
int space = 32;
bool isPal = true;
while (half > 0 && isPal) {
bool startSpace = str.at(start) == space;
bool endSpace = str.at(end) == space;
if (str.at(start) == str.at(end)) {
start++;
end--;
} else if (startSpace || endSpace) {
startSpace && start++;
endSpace && end--;
} else {
isPal = false;
}
half--;
}
info.GetReturnValue().Set(isPal);
}
void Init(Local<Object> exports, Local<Object> module) {
NODE_SET_METHOD(module, "exports", IsPalindrome);
}
NODE_MODULE(addon, Init)
这也许不是最好的实现方式，但它的时间复杂度是O(n)，现在还是可以接受的。我们准备检查上面的代码，首先下面这几行：
void Init(Local<Object> exports, Local<Object> module) {
NODE_SET_METHOD(module, “exports”, IsPalindrome);
}
NODE_MODULE(addon, Init)
暴露IsPalindrome方法，稍后会被Node引用，(有兴趣可以)在Node的源码中看一下NODE_MODULE和NODE_SET_METHOD方法。
另外这段代码有趣的部分：
void IsPalindrome(const FunctionCallbackInfo<Value>& info) {
String::Utf8Value sentence(info[0]->ToString());
std::string str = std::string(*sentence);
我们这里使用了一些v8的类，FunctionCallbackInfo提供调用上下文信息的访问，包括接收者，参数的数量和值，还有方法的持有者。最后，我们使用Utf8Value类将参数转换为std string，用以后续在算法中操作。
是时候衡量这两种实现的性能了，为此我们借助benchmarkjs，它也是jsperf.com内部使用的库：
> npm i --save benckmark
var Benchmark = require('benchmark');
var palindromeC = require('bindings')('palindrome.node');
var palindromeJs = require('./palindrome.js');
var suite = new Benchmark.Suite;
var str = 'a man a plan a cat a ham a yak a yam a hat a canal panama';
suite
.add('Javascript palindrome', function() {
palindromeJs(str);
})
.add('C palindrome', function() {
palindromeC(str);
})
.on('cycle', cycle)
.on('complete', complete)
.run({ 'async': true });
function cycle(event) {
console.log(String(event.target));
}
function complete(a,b) {
console.log('Fastest: ' + this.filter('fastest').map('name'));
console.log('Slowest: ' + this.filter('slowest').map('name'));
}
C palindrome x 1,353,176 ops/sec ±1.98% (80 runs sampled)
Javascript palindrome x 293,383 ops/sec ±1.34% (87 runs sampled)
Fastest: C palindrome
Slowest: Javascript palindrome
走起，C回文比Javascript快了460%！😏😏 提升太惊人了？但是等等，我们有点作弊... 我们使用了两种不同的实现，Javascript的单行比起C++的时间复杂度要更高。我们现在尝试用Javascript实现C++一模一样的算法：
function isPalindrome(str) {
var half = Math.round(str.length / 2);
var start = 0;
var end = str.length - 1;
var palindrome = true;
var SPACE = 32;
var COMMA = 44;
var startSpace, endSpace;
while (half && palindrome) {
startSpace = str.charCodeAt(start) === SPACE || str.charCodeAt(start) === COMMA;
endSpace = str.charCodeAt(end) === SPACE || str.charCodeAt(end) === COMMA;
if (str[start] == str[end]) {
start++;
end--;
} else if (startSpace || endSpace) {
startSpace && start++;
endSpace && end--;
} else {
palindrome = false;
}
half--;
}
return palindrome;
}
C palindrome x 1,370,148 ops/sec ±1.32% (80 runs sampled)
Javascript palindrome x 3,326,042 ops/sec ±0.98% (82 runs sampled)
Fastest: Javascript palindrome
Slowest: C palindrome
神马，Javascript的实现现在更快了240%😲...那还有什么意思？好在我们还可以做些什么来解决这个问题。
引入nan
Node.js的原生抽象
由于V8（Node内核）的变化，保持愉快地跨版本编译原生插件，简直是个小噩梦，而nan的目标就是只保留开发原生Node.js插件的必要逻辑，而无需检查NODE_MODULE_VERSION。
我们原生的实现比js更慢是因为这个：
String::Utf8Value sentence(info[0]->ToString());
std::string str = std::string(*sentence);
这里我们只是把第一个参数转化为std string，但是由于Utf8Value的内部原理，我们付出昂贵的代价来转化。我们现在来看看使用nan是怎么做的：
Nan::Utf8String arg0(info[0]);
char *str = *arg0;
我们现在使用nan Utf8Value来替代v8 Utf8Value，并将其转化为字符数组。我们还做了一些小改动以适应字符数组：
#include <nan.h>
using namespace v8;
void IsPalindrome(const FunctionCallbackInfo<Value>& info) {
Nan::Utf8String arg0(info[0]);
char *str = *arg0;
size_t len = arg0.length();
int half = len / 2;
int start = 0;
int end = len - 1;
int space = 32;
int comma = 44;
bool isPal = true;
bool startSpace;
bool endSpace;
while (half > 0 && isPal) {
startSpace = str[start] == space || str[start] == comma;
endSpace = str[end] == space || str[end] == comma;
if (str[start] == str[end]) {
start++;
end--;
} else if (startSpace || endSpace) {
startSpace && start++;
endSpace && end--;
} else {
isPal = false;
}
half--;
}
info.GetReturnValue().Set(isPal);
}
void Init(Local<Object> exports, Local<Object> module) {
NODE_SET_METHOD(module, "exports", IsPalindrome);
}
NODE_MODULE(addon, Init)
C palindrome x 5,753,415 ops/sec ±1.40% (84 runs sampled)
Javascript palindrome x 3,307,899 ops/sec ±1.28% (84 runs sampled)
Fastest: C palindrome
Slowest: Javascript palindrome
借助nan现在C++比js快了170% 😃
前所未有的大回文
最后，我们来试一个前所未有的大回文，看看更长的字符串性能能否保持或是更好。隆重介绍17,826字回文 😈。结果如下：
C palindrome x 4,636 ops/sec ±1.10% (83 runs sampled)
Javascript palindrome x 1,712 ops/sec ±1.22% (83 runs sampled)
Fastest: C palindrome
Slowest: Javascript palindrome
C++再次获得更好的性能，这次是270%。可能也没那么显著，但是你能发现字符串越长C++的性能会越好。
总结
我们看到了怎么创建并性能测试Node.js的原生addons，可能上面的例子并没有很好的性能，因为我们仅仅处理字符串，但至少手把手展示怎么做。
最后我必须承认很难找到合适的node addons文档和例子，不管怎样，下面推荐我学习途中的一些参考：