[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