12 Dec
2008
12 Dec
'08
4:43 p.m.
On Dec 12, 2008 at 14:04, Henning Westerholt <henning.westerholt(a)1und1.de> wrote:
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.
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
On Thursday 11 December 2008, Andrei Pelinescu-Onciul
wrote:
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.
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. 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. [..]
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.