Candidates for performance optimization

[raymondfeng]

• (see Remove unnecessary allocations from rest handler strongloop/loopback#999)
  https://github.com/strongloop/loopback/blob/master/server/middleware/rest.js#L27
  • we should build the handlers once at middleware level instead of per request)
• (see Optimize performance of http-context strongloop/strong-remoting#157)
  https://github.com/strongloop/strong-remoting/blob/master/lib/http-context.js#L68
  • Remove the usage of closure, use for-loop instead
  • Remove the need to bind(this)
• https://github.com/strongloop/strong-remoting/blob/master/lib/remote-objects.js#L362
  • searchListenerTree is always invoked against the global registry of remoting hooks. For example, User.before and User.after even for message.greet().

[bajtos]

https://github.com/strongloop/loopback/blob/master/server/middleware/rest.js#L27
we should build the handlers once at middleware level instead of per request)

That's already happening, see L38.

https://github.com/strongloop/strong-remoting/blob/master/lib/http-context.js#L68
Remove the usage of closure, use for-loop instead

IMO it's questionable how much performance we can gain by that change. We should measure the performance of both versions and pick up the fastest one.

Remove the need to bind(this)

Definitely, we should use self instead. We should start by fixing this, and only later look into replacing forEach with for-loop.

[bajtos]

https://github.com/strongloop/loopback/blob/master/server/middleware/rest.js#L27
we should build the handlers once at middleware level instead of per request)

That's already happening, see L38.

Having said that, we are creating a new array for each request later on L61 (preHandlers.concat(restHandler)). This should be definitely optimised.

[raymondfeng]

for-loop is much faster than Array.prototype.forEach, see http://jsperf.com/fast-array-foreach. I already used the same technique to optimize juggler before.

[raymondfeng]

L38 doesn't help as the declaration of preHandlers at line 36 is scoped to the handler function, not the middleware factory. As a result, L38 is always evaluated to true.

[raymondfeng]

We should also look into usages that prevent V8 optimization - https://github.com/petkaantonov/bluebird/wiki/Optimization-killers.

https://www.youtube.com/watch?v=NthmeLEhDDM

[bajtos]

L38 doesn't help as the declaration of preHandlers at line 36 is scoped to the handler function, not the middleware factory. As a result, L38 is always evaluated to true.

Good catch!

[raymondfeng]

Another PR - expressjs/cors#35