<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Steve Murphy wrote:
<blockquote cite="mid1193926093.17249.4.camel@digium2" type="cite">
  <pre wrap="">On Wed, 2007-10-31 at 18:46 -0600, Steve Murphy wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">On Wed, 2007-10-31 at 18:05 +0100, Vadim Lebedev wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">...
Well the following is obviously MUUCH faster than the original:

static void pbx_substitute_variables(char *passdata, int datalen,
struct ast_channel *c, struct ast_exten *e)
{

        /* No variables or expressions in e-&gt;data, so why scan it?
*/
        if (e-&gt;data &amp;&amp; !strchr(e-&gt;data, '$'))
                ast_copy_string(passdata, e-&gt;data, datalen);
                return;
        }
        
        *passdata = 0;
        pbx_substitute_variables_helper(c, e-&gt;data, passdata,
datalen - 1);
}


Original:
static void pbx_substitute_variables(char *passdata, int datalen,
struct ast_channel *c, struct ast_exten *e)
{
        memset(passdata, 0, datalen);

        /* No variables or expressions in e-&gt;data, so why scan it?
*/
        if (e-&gt;data &amp;&amp; !strchr(e-&gt;data, '$') &amp;&amp; !
strstr(e-&gt;data,"${") &amp;&amp; !strstr(e-&gt;data,"$[") &amp;&amp; !
strstr(e-&gt;data,"$(")) {
                ast_copy_string(passdata, e-&gt;data, datalen);
                return;
        }

        pbx_substitute_variables_helper(c, e-&gt;data, passdata,
datalen - 1);
}


      </pre>
    </blockquote>
    <pre wrap="">Oh, and yes, I forgot to mention *passdata = 0; vs memset(passdata, 0,
datalen);
Considering that the passdata buffer is 8192 bytes long, just writing
1 byte vs. 8192 bytes WOULD be a huge savings in time. 

BUT, you can't do that. pbx_substitute_variables_helper will not work.
It depends on passdata being nulled out, and it will fail to work
correctly if you go that route.

murf
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Hmmmm. I wrote another letter, that seems not to have made it, saying
that the part about not unnecessarily scanning the e-&gt;data is a good
idea, but my benchmark, there's always a ${} or $[] expression, or both,
so such an improvement won't help... and, that Tilghman has just added
that improvement to trunk... (a good idea is a good idea!)

But your *passdata = 0; idea got me to thinking. I determined to
re-write pbx_substitute_variables_helper_full() to eliminate the need to
zero out that 8K buffer 4 million times (for 4 million priorities to
execute). The further I studied how
pbx_substitute_variables_helper_full() was built, tho, the more I liked
it. So I gave up the idea of rewriting it, to just tweaking it to zero
out the byte after the last byte copied to the output buffer. That
turned out to be pretty simple. There are only 3 places in the routine
where bytes are copied.

That done, there were 2 places, where a 4K buffer was memset to zeroes,
for a recursive call. I got rid of these, also. Then, I went thru all
the source, and got rid of all the memsets (and array initializations)
in all the places it was done, to zero the buffer for
pbx_substitute_variables_helper/_full, and ran my perf measurements
again. Now, without having to zero out between 32 and 48 Gbytes of
buffer, it's now at 100K!!!

See <a class="moz-txt-link-freetext" href="http://svn.digium.com/svn/asterisk/team/murf/fast-ast3">http://svn.digium.com/svn/asterisk/team/murf/fast-ast3</a> for all this
work. If everybody would please review the mods, and test it, I'd
appreciate it. I'd like to merge this into trunk, as soon as possible,
if everyone is willing/no-one objects.

murf

  </pre>
</blockquote>
Steve, you was faster than me... :( <br>
I was doing EXACTLY the same thing....<br>
<br>
Congrats<br>
<br>
<br>
Vadim<br>
<br>
<br>
P.S. Another way to increase substitution perfomance is on first call
'compile' it into a primitive&nbsp; 'machine'<br>
code for a substitution machine. So on subsequent calls the parsing
will be skipped alltogether.<br>
I'd exepect 10 fold perfomance increase this way.<br>
But it will take much more time to develop<br>
<br>
</body>
</html>