如何使用Node.js的原生Addons提升性能(译)

原文:How to get a performance boost using Node.js native addons

也许你已经听说过上千次,但我今天要向你展示什么是Node.js的原生模块,以及你为什么应该关注它们。

Node.js addons是使用C或C++编写的动态链接共享对象,可以使用require()方法加载,并且像其他普通的Node.js模块一样使用。
<small style="text-rendering: optimizelegibility; box-sizing: border-box; font-size: 12.8px;">(译注:addons: 扩展,为保持统一叫法,不予翻译)</small>

说得这么好听,但是,为什么要我写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_MODULENODE_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,可能上面的例子并没有很好的性能,因为我们仅仅处理字符串,但至少手把手展示怎么做。

你可以查看完整的回文addon源码,还有性能测试的例子

最后我必须承认很难找到合适的node addons文档和例子,不管怎样,下面推荐我学习途中的一些参考:

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,491评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,856评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,745评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,196评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,073评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,112评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,531评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,215评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,485评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,578评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,356评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,215评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,583评论 3 299
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,898评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,174评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,497评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,697评论 2 335

推荐阅读更多精彩内容