performance...

[Chuck Remes]

I've started putting amqp-js through its paces. Performance is a tad lackluster though perhaps that can be blamed on the browser (Safari).

When I profile the code, one routine in the "receive" callpath always catches my eye.

receive: function(msg) {

var match = false;
var ex = this.bindings[msg.exchange];
if(ex) {
for(var k in ex) {
var rk = new RegExp("^" + k.replace('.','\.').replace('*','[^\.|$]+').replace('#','([^\.|$]+\.)+') + "$");
if(rk.test(msg.routingKey)) {
match = true;
ex[k].fireEvent("rcv", msg);
}
}
}

//default to the queue callback
if(!match) {
this.fireEvent("rcv", msg);
}
}

I'm not a javascript expert by an means, but is it necessary to create a new RegExp every time this function gets executed? Unfortunately the profilers suck hard enough that it isn't possible to see where all the time is taken up in a specific routine, but whenever I need to do a bit of optimization I usually look at reducing object creation.

Anyway, I'm pumping data into amqp-js on the client side at a rate of about 1 message very 40 ms. That's about as fast as it will go right now (the payload is JSON).

Has anyone else done any benchmarking?

cr

[Dan Simpson]

That method can definitely be optimized.  That said, what kind of performance do you get with logging disabled?

The regex doesn't need to be built on every message, so I will change that and you should see some better performance (assuming the js engine is not doing something fancy like memoization)

--Dan

--
You received this message because you are subscribed to the Google Groups "amqp-js" group.
To post to this group, send email to amq...@googlegroups.com.
To unsubscribe from this group, send email to amqp-js+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/amqp-js?hl=en.

[Dan Simpson]

Alright, I moved the regex compilation to the binding constructor. Try now, and please let me know.

Thanks,
Dan

[Chuck Remes]

Will test this morning and report back.

cr

[Chuck Remes]

It's better. It's now processing more messages per second and exposing  bottlenecks elsewhere in the system. This code is no longer the bottleneck.

Thanks for the fix.

cr

--