Hi, I'm wondering which solution (A or B) is more efficient in case method is NOT an INVITE:
A) if ( (method=="INVITE") && (isflagset(5) || isbflagset(6)) )
B) if ( mehtod=="INVITE" )
My question is: Is faster B because does less comparasions? or does OpenSer break A conditional during first condition (method=="INVITE") because it's false so then A and B are equally efficient?
And which is more efficient (C or D) when all the conditions are true?
C) if ( (method=="INVITE") && (isflagset(5) || isbflagset(6)) ) { ....
D) if ( method=="INVITE" ) { if ( (isflagset(5) || isbflagset(6)) ) { ...
Thanks for any explanation. Best regards.
Iñaki Baz Castillo wrote:
Hi, I'm wondering which solution (A or B) is more efficient in case method is NOT an INVITE:
A) if ( (method=="INVITE") && (isflagset(5) || isbflagset(6)) )
B) if ( mehtod=="INVITE" )
AFAIK the conditions are checked in the order they appear and stop as soon as possible. In your case in != INVITE it should be the same.
Further, if you use is_method("INVITE") it is even faster.
regards klaus
My question is: Is faster B because does less comparasions? or does OpenSer break A conditional during first condition (method=="INVITE") because it's false so then A and B are equally efficient?
And which is more efficient (C or D) when all the conditions are true?
C) if ( (method=="INVITE") && (isflagset(5) || isbflagset(6)) ) { ....
D) if ( method=="INVITE" ) { if ( (isflagset(5) || isbflagset(6)) ) { ...
Thanks for any explanation. Best regards.
El Tuesday 16 October 2007 15:18:58 Klaus Darilion escribió:
Iñaki Baz Castillo wrote:
Hi, I'm wondering which solution (A or B) is more efficient in case method is NOT an INVITE:
A) if ( (method=="INVITE") && (isflagset(5) || isbflagset(6)) )
B) if ( mehtod=="INVITE" )
AFAIK the conditions are checked in the order they appear and stop as soon as possible. In your case in != INVITE it should be the same.
Nice to know it.
Further, if you use is_method("INVITE") it is even faster.
Ops, I didn't know that. Ok, I'll change all my script :)
Thanks again.
Hi,
AFAIK the conditions are checked in the order they appear and stop as soon as possible. In your case in != INVITE it should be the same.
Further, if you use is_method("INVITE") it is even faster.
To be honest, I don't think it really cares in standard scenarios. An optimization of some microseconds is next to nothing compared to the duration it takes to perform a db or radius request for example.
Just my 2 cents, Andreas
Andreas Granig wrote:
Hi,
AFAIK the conditions are checked in the order they appear and stop as soon as possible. In your case in != INVITE it should be the same.
Further, if you use is_method("INVITE") it is even faster.
To be honest, I don't think it really cares in standard scenarios. An optimization of some microseconds is next to nothing compared to the duration it takes to perform a db or radius request for example.
that's true
Hello,
if one is concerned about the efficiency of some config snippets, then use the benchmark module to see which is faster. Practically, that is the scope of the module.
Cheers, Daniel
PS. Indeed, the conditionals try to stop as soon as possible in case of and/or tests.
On 10/16/07 17:34, Klaus Darilion wrote:
Andreas Granig wrote:
Hi,
AFAIK the conditions are checked in the order they appear and stop as soon as possible. In your case in != INVITE it should be the same.
Further, if you use is_method("INVITE") it is even faster.
To be honest, I don't think it really cares in standard scenarios. An optimization of some microseconds is next to nothing compared to the duration it takes to perform a db or radius request for example.
that's true
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
El Tuesday 16 October 2007 15:34:15 Andreas Granig escribió:
Hi,
AFAIK the conditions are checked in the order they appear and stop as soon as possible. In your case in != INVITE it should be the same.
Further, if you use is_method("INVITE") it is even faster.
To be honest, I don't think it really cares in standard scenarios. An optimization of some microseconds is next to nothing compared to the duration it takes to perform a db or radius request for example.
About duration sure you are right, but what about CPU usage? An external DB or Radius query can take long time but during that time the CPU is no used as if it's doing routing.
-
Andreas Granig -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Klaus Darilion