Re: move constructors likely a requirement

[Rik]

On 08/29/2019 06:43 PM, John W. Eaton wrote:
> 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.

This sounds exciting.  I would probably proceed conservatively, i.e.,
recover past performance by reverting to the previous code pattern, before
embarking on JIT which could be a very big project indeed.

>
> 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?
>

Potentially tedious, but not difficult in the same way that locating and
solving a performance issue is.  Ideally we would have tests that are
fine-grained enough to test one subsystem at a time so that improvements in
one area aren't offset by losses in another so we don't perceive what is
really happening.  Since you know the architecture the best I think you can
probably make a stab at the partitioning and which subsystems those might be. 

I don't think it matters when we establish a baseline because the results
are only necessary to validate whether a proposed code change caused an
increase or decrease in performance.  If we start now, we should see
decreases for a while as the code is improved.  After several iterations
the size of the decreases will get smaller until we decide that it isn't
worth working on anymore.  But right now, I suspect there is still
low-hanging fruit.

--Rik