3x faster setImmediate

[andrasq]

Checklist

• tests and code linting passes
• a test and/or benchmark is included
• the commit message follows commit guidelines

Affected core subsystem(s)

Description of change

Sped up setImmediate processing by 60% to over 400% through faster linkedlist creation,
faster immediate object creation, not wrapping closures around callbacks, and invoking
the callbacks faster from an optimizable function without using .call

Sped up clearImmediate by delaying the linked list update until processImmediate pulls the
immediate off the queue, where it's done more efficiently. This speeds up clearImmediate 3x,
with the benefit stacking on top of the setImmediate speedup.

Added benchmarks for setImmediate and clearImmediate.

[mscdex]

This should be const.

[mscdex]

I also wonder if there would be any performance benefit to instead creating a new instance of an object that doesn't inherit from Object.prototype? For example:

function LinkedListNode() {
  this._idleNext = null;
  this._idlePrev = null;
}
LinkedListNode.prototype = Object.create(null);

function create() {
  const list = new LinkedListNode();
  init(list);
  return list;
}

[andrasq]

changed to const.

I tried the Object.create version above, and it's inclusive. Some test runs (10-20 sec runs)
show a 2% advantage one way, then changing the loop/repeat count (where loops*repeats
is the number of objects created) flips the advantage the other way.

[mscdex]

Perhaps the benchmarks could more closely resemble the existing setImmediate() benchmarks in benchmark/misc (which probably need to be moved to benchmark/timers now, but that is a separate PR)? Specifically when I landed setImmediate() performance improvements awhile back, @bnoordhuis had commented that the callbacks should not reference variables in parent scopes if at all possible.

[Fishrock123]

this is a breaking change

[Fishrock123]

Ok, nvm, #6206 has not landed yet

[bengl]

I don't think this would be breaking if #6206 had landed, as it doesn't get rid of the Immediate class, and instead just moves the property assignments into the constructor.

[benjamingr]

That code changed since the comment was left here.

[andrasq]

@mscdex re the benchmarks, oops, I didn't realize misc already had immediate tests.
I patterned the ones I wrote on the timers/timeout.js benchmarks ("patterned" as in cut-and-paste
reused them, pretty much).

Each test function is called once, the closure should be built once and reused across all callbacks.
The tests are strctured as eg

function test() {
  function cb() { if ... bench.end(K) }
  for (...) { setImmediate(cb) }
}

Changing it to

  for (...) { setImmediate(function cb() { if ... bench.end(K) }) }

halves the throughput, suggesting that the closure is reused in the above case and
not reused below. (The tests also measure the cost of passing arguments to the callback,
and the 0-argument depth test needs a closure to know when to stop.)

A different question is whether my benchmarks add enough value to keep, or if I should just ditch them
in favor of the ones that already exist.

[benjamingr]

I don't really understand why this change is needed or is helpful but I guess it does clean things up a little.

[Fishrock123]

prevents a hidden class change

[andrasq]

at top-level it was changed to match processImmediate (and it cleans things up a bit).
In processImmediate it's a speedup, L.create() returns an access-optimized object.

[benjamingr]

I bet the object ends up being access-optimized after enough runs anyway. Not to mention we can make objects access-optimized explicitly.

That said - this change improves style anyway and is better coding.

[andrasq]

probably, though depends on how many immediates are queued in an event loop cycle.
The immediateQueue is re-created every time, so the optimization would not persist
(and there would be a run-time cost for the conversion).

Out of curiosity, what are the ways of creating access-optimized objects? I know about
objects created with { ... }, the prototype properties of new objects, (the this. properties
as assigned in the constructor?), and assigning an object as the prototype of a function
forces optimization. Any others?

[benjamingr]

@andrasq conveniently, here is a StackOverflow answer I wrote about a technique petkaantonov used in bluebird (with making an object as a prototype of a function).

This also works with Object.create so I guess that's another one.

this. properties assigned in the constructor is the "standard" way though, it's even "easier" than object literals and it makes the fact it's static obvious to v8 (object literals work fine too usually).

[benjamingr]

Just to be explicit - this specific change LGTM, even if it's not faster but it probably is given the old code.

[andrasq]

that's a great writeup, and a handy reference, thanks!

[andrasq]

pushed edits (some more consts)

[benjamingr]

Minus new Immediate instead of createImmediate - looks good to me.

Thanks for this fix.

[andrasq]

pushed edits (new Immediate)

[benjamingr]

LGTM although I meant for new Immediate to take the arguments in the constructor.

[andrasq]

@mjsalinger perhaps some of the commits got squashed; all the expected edits are there.
The 4 (less 1) original + 8 code review change sets got merged as 3 commits.

[MylesBorins]

I'm setting this as don't land. please change to LTS watch if you think this should land in LTS

[Fishrock123]

@thealphanerd if it cleanly applies you should be able to land it

[MylesBorins]

@Fishrock123 it does not land cleanly without other timers changes

[Fishrock123]

@thealphanerd ok, probably not important unless it is needed for other fixes. (Although it would be nice.)

[zhoujinhai]

@Fishrock123 I have the same problem , did you save it?

<--- Last few GCs --->

[9852:000001B18947FDB0]   770113 ms: Mark-sweep 1401.2 (1457.9) -> 1398.7 (1457.9) MB, 16.4 / 0.0 ms  (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 18 ms) allocation failure GC in old space requested
[9852:000001B18947FDB0]   770136 ms: Mark-sweep 1398.7 (1457.9) -> 1398.6 (1426.4) MB, 21.0 / 0.0 ms  last resort
[9852:000001B18947FDB0]   770158 ms: Mark-sweep 1398.6 (1426.4) -> 1398.6 (1425.9) MB, 22.5 / 0.0 ms  last resort


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0000003FB9CA9891 <JS Object>
    2: new constructor(aka Request) [E:\nodecrawler\node_modules\request\request.js:128] [pc=0000004DC395835B](this=000000583D4E4AD1 <a Request with map 0000035C122A1B51>,options=000000583D4E4DC9 <an Object with map 0000025475FDD539>)
    4: request(aka request) [E:\nodecrawler\node_modules\request\index.js:54] [pc=0000004DC3957474](this=000000530CD82311 <undefined>,uri=000000583D4E8241 <an O...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

my code is here:
var crawler = require('crawler');
var config = require('./config');
var fs = require('fs');
// var videoList = config.videoList;
//var read = require('./read');
var debug = require('debug')('nightmare:crawler');

console.time("程序运行时间");//开始运行时间
//从videoList文件中获取视频列表
var read = fs.readFileSync(__dirname+'/videoList.json',function(err){
	if(err){
		console.log(err);
	}
	debug('读取videoList文件');
	console.log('successed!');
});
var videoList = JSON.parse(read);

var informationList = [];
var c = new crawler({
	// maxConnection : 1000,
	//rateLimit : 1000,
	forceUTF8 : true,
	callback : function(error,res,done){
		if(error){
			console.log(error);
		}else{	
			information(res,done);
			done();
		}
		// console.log(informationList);
		// console.log(informationList.length);
	}
});

// //爬取订阅号列表

for(i=0;i<videoList.length;i++){
	c.queue({
		uri: videoList[i].url,
		proxy: 'http://127.0.0.1:61481'
	});
}