PSL Optimization
The following sections describe PSL optimizations:
= , grep() or index()
These are three different functions to do string matching. The optimizer will not change one command with another, each function has it's own reason of existence with its own backend code. I'll try to spend some time on each of the different functions and hope this helps you understand why it is working this way.
text = pattern
Returns 1 if regular expression pattern matches the text, otherwise zero. The text can be multi lined. This is an operator. An operator takes two arguments are returns a third argument in a single QUAD instruction. The operation is a regular expression match and it will unconditionally behave like a very fast version of grep()... no options, no checking, no return values, besides 1 or zero. Whenever the optimizer can, it will "pre-execute" this operator at compile time. That means if the two arguments are static (hardcoded), using = will have no run time overhead. The execution of = is fast (much faster than grep and I guess a little bit faster than index), but
- Will return 0 or 1
- Will always use regexp (be careful when your pattern contains regexp characters)
grep(pattern,text,options);
Returns the lines of text that match pattern. This is a build-in function and will therefore require a quad more to execute than an operator. Has options to tweak the execution, and will try to determine if pattern contains regexp or not. It works line by line and if pattern does not contain regexp it will use a sort of index() function (without compiling and executing the regular expression) to optimize for speed. This is the slowest of them all on a line mode, but a lot faster then writing your own using = and for each line on a block of text. The optimizer will not "pre-execute" the function, even if the arguments are hardcoded (or static).
index(text,string);
Does not work with regular expressions. It will return the position of string within text.Works on multilines and very useful to see if a certain word appears in a block of text. This is a PSL function with less overhead than grep(). The optimizer will "pre-execute" in case both arguments are hardcoded (or static)
multi-string grepping
The PATROL grep() function supports multiple string matching.
grep("string1\\\|string2",text);
PSL readln() limitation
The limitation of the readln() is that the length is limited to 4095 characters. Below is a function call SafeReadln which will readln and if the err 57 occurs, try reading again until the EOL is seen.
function Safe_Readln(chan)
{
local psl, x, data;
pos = ftell(chan);
x = PslDebug;
# Turn off runtime error reporting
PslDebug = 0;
data = readln(chan);
while (errno == 57)
{
# E_PSL_READLN_TRUNCATED
pos = pos + 4095;
fseek(chan, pos, 1);
data = data.readln(chan);
}
PslDebug = x; # restore runtime error reporting
return data;
}
readchan = fopen(long le, "r");
if (! chan exists(readchan))
{
print("error <".errno."> opening <".long le.">\n");
exit;
}
longbuf = Safe Readln(readchan);
print("========== longbuf =============\n");
print("long buf is <".length(longbuf)."> bytes long\n");
print(longbuf);
print("=========end of longbuf ========\n");
print("=========end of longbuf ========\n");
Evaluation short-circuiting
Operators && and || do not short-circuit evaluation. In other words, the second operand of these operators is always evaluated and never short-circuited by the first expression. The following are some examples of expression short-circuiting:
- if (expr1 && expr2) {....
- PSL evaluates both expressions
- If expr2 is expensive ....
- if (expr1) { if (expr2) {....}}
- compiler generates more quad that leads to run time overhead. If expr2 is a light expression such as (x==2), first format can be used. However, if expr2 is complex, first format causes more overhead.
Optimize loops
Loop optimizations provide the following:
- Reduces loop iteration
- Eliminates common subexpression. If there is a common subexpression, it should be evaluated outside the loop.
- Provides invariant pre-computing loops