On 8/24/19 1:01 AM, Rik wrote:
The only thing it does is assign the static value 13 to the variable
z. In
3.2.4 this took 0.17 seconds and now it takes 0.96.
I think I would start investigations with this script. Is it the
creation
of a new octave_value for 13 every time? Is it assignment?
I spent a lot of time over the last week looking at the interpreter.
It's a bunch of different things, but the biggest factor seems to be
using the tree walker pattern instead of just doing virtual dispatch to
evaluation methods in the parse tree objects themselves. I think I can
speed it up considerably, possibly even get back much closer to the
3.4.3 performance just by going back to something more like what we used
to have for the evaluator (but keeping evaluator state in an object
instead of as global data). Another option is to implement a byte code
interpreter instead of directly evaluating the parse tree, but that is
more work. OTOH, it might be instructive and helpful for JIT compiling.
I'll try to provide a more complete summary of what I found with some
patches tomorrow.
This experience does show that we need some kind of performance testing,
and not just an aggregate time required to running the test suite. We
need a set of tests to check performance of specific features. But I'm
not sure how best to do comparisons. What do we use for baseline values?