octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Functions calls got slower between Octave 2.9.5 and 2.9.6 through .10


From: John W. Eaton
Subject: Functions calls got slower between Octave 2.9.5 and 2.9.6 through .10
Date: Thu, 26 Apr 2007 17:13:48 -0400

On 22-Apr-2007, Luis F. Ortiz wrote:

| As you can see, something went awry between Octave 2.9.5 and 2.9.6,  
| and has stayed bad since, to
| the tune of 20% less goodness.

The following patch will help slightly.  The other change to this
function that was made between 2.9.5 and 2.9.6 that can't be skipped
is the addition of the lines

  octave_call_stack::push (this);

  unwind_protect::add (octave_call_stack::unwind_pop, 0);

| The "Calls Per Ack" column is the number of "Calls" divided by  
| 172,233*2.   It gives you hint about how many
| times a function is executed as a result of each call to quack().   
| Some  numbers are scary-big, like the
| number of times the octave_value destructor is called (104 Calls per  
| ACK) or the Array<std::string> destructor
| (29+ times per ACK).   I don't at all understand why so many  
| octave_value and string array objects are being
| created for so simple a program, they are not directly big chunks of  
| time.

I'd guess they are happening because of creating and destroying
octave_value_lists and/or just producing values from expressions.
I'd bet that many calls are copy constructors where all that happens
is an increment in the reference count and that the destructor calls
are similarly just decrementing the count.

| Most of the time is pretty spread out
| among the classes unwind_protect::, symbol_table::, and tree_*::.

| It is almost as if the cost of doing all of these varied operations  
| just increased, not one method or one class.

I don't see how that would be true unless the compiler also changed.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]