Hotspot identification

[Rik]

Some code to inspect.  I am posting this on bug report #56752, but CC'ing
the Maintainers-List as I think it is of general interest to developers.

+verbatim+
- 43.69% octave::tree_evaluator::evaluate_internal
   - 41.90% octave::tree_evaluator::visit_index_expression
      - 14.81% octave::symbol_table::find_function
         + 14.69% octave::symbol_table::fcn_table_find
      - 11.93% octave::tree_evaluator::convert_to_const_vector
         + 8.44% octave::tree_evaluator::evaluate
           0.93% octave_value_list::octave_value_list
           0.65% octave_value_list::octave_value_list
      + 4.56% octave_builtin::call
        1.35% Array<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >::operator=
        1.14% Array<octave_value>::operator=
        1.04% octave_value_list::octave_value_list
        0.93% Array<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >::~Array
        0.85% Array<octave_value>::~Array
        0.68% octave::tree_evaluator::is_variable
        0.59% octave_value_list::operator=
-verbatim-

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.

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.

Second hotspot in lvalue.

+verbatim+
- 19.84% octave::tree_index_expression::lvalue
   - 15.48% octave::tree_evaluator::convert_to_const_vector
      + 5.44% octave::tree_evaluator::evaluate
      + 4.60% octave_value_list::octave_value_list
        1.57% octave_value_list::octave_value_list
        0.91% std::__cxx11::_List_base<octave_value_list,
std::allocator<octave_value_list> >::_M_clear
     0.54% octave::octave_lvalue::set_index
-verbatim-

class octave_value_list is based on the Array class "Array<octave_value>
data;" which may, in effect, be a heavyweight constructor.  Perhaps it
would be faster to base octave_value_list off one of the list classes in
the STL.  Given that one doesn't actually need a lot of insertion/deletion
of nodes, std::vector might be a good choice.  I wouldn't go that
direction, however, unless there is more proof that this is an issue.

Third hotspot:

+verbatim+
- 6.86% octave::octave_lvalue::assign
   - 6.64% octave_value::assign
      - 6.25% octave_value::subsasgn
         - 6.19% octave_base_matrix<NDArray>::subsasgn
            - 5.34% octave_base_value::numeric_assign
               + 3.40% oct_assignop_assign
                 0.68% __strlen_avx2
-verbatim-

--Rik