Jak to się dzieje, że opóźnienia Q są tak powolne w Node.js?

Question

Więc stworzyłem ten prosty serwer testowy w Node.js
Zawsze, gdy robię bezpośrednią odpowiedź, otrzymuję żądań/sekundę (szybko!). Kiedy tylko zawijam prostą Q odroczoną wokół niego, to spada do żądań/sekundę (4 razy wolniej!). Czy ktoś może wyjaśnić tę ogromną różnicę?

// Requires 
var server = require('http'); 
var q = require('q'); 

// Start server 
var http = require('http'); 
http.createServer(function(request, response) { 

    // Comment out either of two below sections 

// Without deferred 
// 2200 reqs/second 
response.writeHead(200, {"Content-Type": "text/html"}); 
response.write("test"); 
response.end(); 

// Q deferred 
// 580 reqs/second 
var deferred = q.defer(); 
deferred.promise.then(function() { 
    response.writeHead(200, {"Content-Type": "text/html"}); 
    response.write("test"); 
    response.end(); 
}); 
deferred.resolve(); 
}).listen(1234); 

Answer 1

Przyczyny jestem świadomy, to:

1. Q wykorzystuje Object.freeze, a to spowalnia V8 o wielkości

2. Wiele nextTick połączenia (już wspomniano w uwagach) . Nie powinno to jednak dotyczyć najnowszej wersji Node.js (v0.10), ponieważ dodatkowe nakłady są minimalne.

Answer 2

Edit: wydajność poprawiła się znacznie od stacktraces zostały wyłączone od Q 0.9.6. (Można je ponownie włączyć w celu debugowania za pomocą Q.longStackSupport = true;)

Oryginał: obietnice Q są powolne, ponieważ przechwytują pełny ślad stosu przy każdej obietnicy, aby pomóc w debugowaniu. To bardzo wolno. Możesz je wyłączyć za pomocą Q.longStackJumpLimit = 0; (która prawdopodobnie będzie domyślna w następnej wersji). Znaleźliśmy około 30-krotne przyspieszenie, wyłączając je. Możesz dowiedzieć się więcej tutaj https://github.com/kriskowal/q#long-stack-traces

Było też kilka performance work on the nextTick implementation, ale myślę, że powyższy jest główny powód.