[SR-Dev] operators and variables

Andrei Pelinescu-Onciul andrei at iptel.org
Fri Dec 12 15:43:46 CET 2008


On Dec 12, 2008 at 14:04, Henning Westerholt <henning.westerholt at 1und1.de> wrote:
> On Thursday 11 December 2008, Andrei Pelinescu-Onciul wrote:
> > It would be better to have different operators for strings and for
> > integers. Right now we have '+', '==' and '!=' that can be used both for
> > strings and integers. The problem with this approach is that it makes
> > some optimizations impossible, especially when combined with dynamic
> > typed variables (avps or pvars). '+' is especially bad because one
> > can tell what type ($v + x) has only at runtime.
> >
> > I think having perl like operators would help a lot:
> > - '.' for string concatenation (instead of reusing '+'), e.g.:
> >  $v= "foo" .  "bar"
> > - 'eq' instead of == for strings, e.g.: $v eq "bar"
> > - 'ne' instead of != for strings, e.g.: $v ne "bar"
> 
> Hi Andrei,
> 
> first of all, thanks for the work you've done so far for the config scripting.
> I understand the problem with the existing operators. But from the user POV i 
> doubt that changing this is really worth the effort. This would break 
> compatibility with all existing scripts, many documentation out there would 
> be obseleted and must be updated and so on.
> 
> I don't like the 'eq' and 'ne' that much, for me '==' and '!=' is more 
> intuitive as its used in most other programming languages.
> 
> Can you estimate the performance benefit that would be possible with this 
> optimisations? If its in the range of a few percent, then we should not 
> bother about this. The server is really fast enough in my experience, and 
> CPUs getting more cores every year.

It depends on the complexity of the expressions. There are a lot of
optimizations which cannot be made right now => more work at runtime for
the expression evaluator.

> 
> > We could support them right now in parallel with the old ones and
> >  obsolete +, ==  and != for strings in the future (but that means we
> >  still cannot optimize '+' in all the cases) or switch right now
> > (maybe with some old compat switch which will support old scripts
> > style).
> 
> I'd prefer to not introduce too much compatibility layers, this makes 
> debugging and maintaining both the code and the config script more harder 
> then necessary in my experience.
> 
> > The question is how much are they used right now. While I think '==' and
> > '!=' are used quite often, I'm not sure about '+' for strings (and '+'
> > is the most important anyway).
> 
> I think the '+' is also commonly used, althought not that much as == and !=, i 
> agree. 
> 
> > Note: we can still support '==' and '!='  for condition tests not
> > involving variables (e.g. method=="INVITE", uri=="sip:foo" a.s.o.).
> 
> IMHO having different operators for different type of variables would be 
> confusing. The config script language is already quite complicated for 
> the "normal" administrator or system developer that don't have the luxury of 
> working the whole day with SER/ Kamailio.


I think even more confusing is having errors at runtime due to type
mismatches. It's way better to have them at startup or when checking the
config (-cf ...) rather then at runtime (who tests all the possible
branches in his config?).
So the trade-off is having different operators for better performance and
better error detection at start-up/config check or using same operators
and having type mismatch errors at runtime.


> 
> > [..]
> > In the future it would also be much better to have typed script vars
> > (e.g. int $var1). This would help a lot in checking the script for
> > correctness. With the dynamic typed vars, one has to run the script to
> > find errors. It would also help in optimizing, but not so much if we
> > separate the operators, like above.
> 
> Having this typed script vars would be ok, but i rather prefer keeping it 
> simple and compatible here too, if this brings not a substancial performance 
> benefit.

It brings less performance then the operators changes, but it will allow
for detecting a lot more errors at start-up rather then at runtime
(which IMHO is a huge advantage).


Andrei



More information about the sr-dev mailing list