[Octave-bug-tracker] [bug #56752] Performance slowdown from version 3.2.4 through to current dev branch

[Rik]

Follow-up Comment #11, bug #56752 (project octave):

Some code to inspect.  I am CC'ing the Maintainers-List as I think this is of
general interest.


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


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.


- 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


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:


- 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





    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?56752>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/