Hi Henry,
I was under the impression that an EVAL calls the same compiler
that an I-type does, and that any expression optimization would be
done therein.
As far as I know, EVAL does indeed call the same compiler. As I think you
realise, the point is that an I-type expression such as
1: I
2: SPACE(3)
(which I have seen used to get differing column spacings) will compile to a
pcode sequence that produces a string of three spaces. This does not tell us
how the query processor will then go on to use it. A "normal" I-type
expression, whether from the dictionary or from use of EVAL, would be
executed for each occurrence of it in the report, typically once per record.
In the case of my spacing expression above, the query processor would
actually only need to evaluate the expression once and then drop it into the
report as a constant item.
I think that this is what the original poster was asking about. I have no
idea whether UV does this (QM does). Your experiment seems to tell us.....
Here are some empirical results using UniVerse 10.2.7:
TIMEIT 50 COUNT VOC WITH F1 = 'V'
COUNT VOC WITH F1 = 'V'
Elapsed 1.3006
TIMEIT 50 COUNT VOC WITH F1 = EVAL "'V'"
COUNT VOC WITH F1 = EVAL "'V'"
Elapsed 5.135
This suggests that the query processor does not detect that the result of
the evaluation is a constant and optimize its execution.
No, I think that this is actually showing the opposite. The query was
considerably faster where your test was a simple literal
WITH F1 = 'V'
whereas the EVAL expression added a further four seconds to your query. If
the query processor detected that
EVAL "'V'"
was a constant and optimised it I would expect both queries to take the same
time. It does look as though it is evaluating the expression for every
record.
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
