Re: Hotspot identification

[John W. Eaton]

On 8/13/19 2:09 PM, Rik wrote:

> I'm not sure how the symbol_table is organized, but it is taking a long
> time to find functions.  If we are using a std::map from STL which is based
> on a log2 lookup then perhaps a change to std::unordered_map which is based
> on hashes and O(1) lookups would help.

Function lookup is slow.  We have to check for overloaded functions. 
See fcn_info::fcn_info_rep::xfind in fcn-info.cc for all the things we 
look for before finding a built-in function.  Is there some better way 
to do it?  For example, is there a way to cache a previous lookup and 
not have to search again if we know that the load path has not changed 
and no new overloaded functions could possibly be found?

I think the lvalue thing is complicated by having to support the special 
meaning of "end" inside index expressions.  As I recall, there are some 
weird cases we try to handle for compatibility.  Maybe there are also 
better ways of doing that.
> There also seems to be a lot of creation, assignment, destruction of
> objects.  Worst case, we have objects with heavyweight constructors.
> Fixing that would require making the constructors/destructors do less, or
> introducing an entirely different lightweight object.

Yeah, octave_value_list is a weird object that should probably be 
replaced by a real list, or an object based on a standard library object 
instead of Octave's Array<T>.

> Second hotspot in lvalue.

I think the lvalue thing is complicated by having to support the special 
meaning of "end" inside index expressions.  As I recall, there are some 
weird cases we try to handle for compatibility.  Maybe there are also 
better ways of doing that.

jwe