Re: Slowup in 2.1.54

[John W. Eaton]

On 18-Feb-2004, Paul Thomas <address@hidden> wrote:

| One thing that I have been trying to analyse is what proportion of the 
| time is devoted to doing what kind of task in, say, a simple binary 
| operation and assignment.  Apart from the obvious overheads, such as 
| array bound checking, it strikes me that leaving open the variable 
| types, until the last moment, is quite an expensive (if not the 
| dominant) use of time.  

Perhaps.  I have not tried to profile it.  Another thing that could
make the interpreter slow is that because it is a simple tree-based
interpreter, the evaluator results in a pointer-chasing problem, which
can be slow (or at least slower than a stack-based interpreter) on
modern processors becuase you have to load the data for a given node
in the tree and then look at the pointers it contains before you can
load the next node(s) in the tree.  Also, the interpreter code is
spread out all over the place, so it probably doesn't fit (and stay)
in a cache very well.  But this is just wild guessing from someone who
doesn't really know that much about the details.

| I wonder if the parser can have a stab at identifying the types and, 
| when it is possible, a specific tree_expression substituted for the 
| general one?

Type inference will be the hardest part of writing a good Octave
compiler.

jwe