14 Dec
2012
14 Dec
'12
8:16 p.m.
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(a)tutpro.com> 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.
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.
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.
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.
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
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev