On 03/12/2009 09:59 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
working to integrate the PV module I reached the AVPs and after a short analyze I wonder (and ask you) whether you should drop the naming scheme we have in Kamailio (integer id and string name) and stick to string names all the time.
i'm using exclusively integer ids and would oppose dropping them. this kind of radical change simply cannot be done unless you can do it such a way that integer names are internally auto-converted to strings. this change would affect not only the script, but also db tables where all my avp name columns are ints.
the modules that load the AVPs should take care of keeping only string names inside. However, s: and i: are only indications of the name type in config file. Inside the code these are marked by flags.
I do not know how you load the avps, but in database (usr_preferences table), the avp name column is string. The type is indicating whether to convert to int or keep it as string.
i once looked at kamailio code and got the feeling that lookup with integer names was faster than with string names and therefore started to use integer names.
Did you measure how faster is? Here some details about the avp name and matching algorithm:
- if the avp has id name, then this is kept on a 16b field and nothing else - if the avp has string name, then a hash id is computed and kept in the 16b and the name in a str
When matching ids, then the 16b fields are compared. When matching strings, then the 16b fields are compared, if equal, then the length of the names are compared and if equal, the content of names are compared.
At the end it is about code complexity vs. some potential performance.
The benefits I see:
- complexity in dealing with integer id or string name
- avp name aliases removed
i have never used name aliases.
not using them as well, I'm using M4.
Cheers, Daniel