i didn't get any comments about needless script time calculation of xavp name hash values.
one hack to avoid the hash calculation could be such that if str *name passed to xavp api functions has len=0 then s contains pre-calculated hash value.
-- juha
Hello,
there are collisions on hash id, you can't rely on it as unique id.
I wanted to comment, but comment but didn't get to it yesterday, caught by other tasks.
Have you measured the impact? The same is done for avp with string names and there were no complains. All the operations are in memory and for such names which are quite short, there are not so many extra operations.
The option would be to store the id along with the string in pv name structure, but then it increases the memory, not only for xavps, but for all pv specs. SER guys dropped usage of avps with integer id because the overhead for using just string names was insignificant, compared with the complexity of dealing with both.
Probably optimizations can be done in lot of places, but at expense of something else, like more memory or more complexity (translated in harder code management).
Cheers, Daniel
On 12/14/12 6:41 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
there are collisions on hash id, you can't rely on it as unique id.
i didn't propose to rely on uniqueness of the hash, but only that the hash value could be calculated for module params (and constant script xavp names) once at proxy startup rather than every time during response/reply processing.
i haven't measured the impact. it just felt strange that something that can be easily done only once is done constantly during script processing.
i have not mentioned avps, only xavps. also, my proposal did not increase memory usage and since use of the optimization is not mandatory, it did not increase complexity either.
but never mind.
-- juha
Since there are so many places in the code where data is pre-calculated and then repeatedly reused from within the routing script (DNS names, header parsing, database caching), I have often wondered whether it would perhaps make sense to generalize this somehow. For example, if you need to perform an operation that you know is time consuming, you'd use some kind of framework to see whether this operation has been performed before and if yes, fetch the data from memory. If it hasn't been performed before, you run the function and then save the result. Something along the lines of Dynamic Programming:
http://en.wikipedia.org/wiki/Dynamic_programming
There are many places in the code where this could be applied to speed things up: header parsing, name resolution, database operations, expressions working with avps.
-Jan
On Fri, Dec 14, 2012 at 8:17 AM, Juha Heinanen jh@tutpro.com wrote:
-
Daniel-Constantin Mierla -
Jan Janak -
Juha Heinanen