octave-maintainers
[Top][All Lists]
Advanced

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

Re: Functions calls got slower between Octave 2.9.5 and 2.9.6 through .1


From: Luis F. Ortiz
Subject: Re: Functions calls got slower between Octave 2.9.5 and 2.9.6 through .10
Date: Fri, 27 Apr 2007 07:51:04 -0400

On Thu, 2007-04-26 at 17:13 -0400, John W. Eaton wrote:
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.  
Sorry to be a pest this early in the morning, but I did not see the patch in a following message or this message.
Did I miss it?

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);

One thing I noticed recently was that in src/pt-bp.h, the MAYBE_DO_BREAKPOINT
macro was altered and now unconditionally calls octave_call_stack::current() when
perhaps this could be conditionalized on tree::break_function being set.

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

The nice part of the simple ACK program is that one can predict almost exactly how many
of the 'octave_value' objects are the result of _expression_ evaluation and as members of
octave_value_lists.   My bed prediction is off by a factor of 10X, which obviously means my
understanding of where they are coming from *has* to be faulty.

| 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.
In this case, the measurements were all made with the same compiler (3.3.5) and same
sets of accessory libraries.


reply via email to

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