bugGNU Octave - Bugs: bug #62006, High function calling overhead

 
 

bug #62006: High function calling overhead

Submitter:  Rik <rik5>
Submitted:  Tue 08 Feb 2022 06:14:58 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 20 Mar 2024 03:17:38 AM UTC, comment #4: 

Obsolete version

Anonymous
Sat 12 Feb 2022 06:36:21 PM UTC, comment #3: 

Rik, see also https://savannah.gnu.org/patch/?10147 and some other recent proposed changes from the same contributor.  I'm not sure I agree with all of those, but he has also looked at eliminating some allocations.

John W. Eaton <jwe>
Group administrator
Sat 12 Feb 2022 06:05:46 PM UTC, comment #2: 

I think Octave is doing a lot of malloc/free operations, probably more than we need, and which is related to the creation of temporary objects such as returning octave_value objects or octave_value_list objects from functions.  That is going to be hard to quickly fix.

The one thing that does strike me is the __nss_database_lookup which is taking 7.4% of the time.  Is this a consequence of having remote directories on the PATH for Octave?  That seems like a lot of database lookups.

Rik <rik5>
Group administrator
Thu 10 Feb 2022 09:14:51 AM UTC, comment #1: 

Attached profiles obtained with google-pprof: flat text profile and graphical representation. Scripts run at N=1.e7, since the profiling granularity was quite course, not sure these results already have enough statistical significance.

Time spent in lookin up the function the symbol table and executing the call.

(file #52836, file #52837)

A.R. Burgers <arb>
Tue 08 Feb 2022 06:14:58 AM UTC, original submission:  

I used the following script to benchmark the calling overhead in Octave.


N = 1e6;

tic;
for i = 1:N
  ## Empty for loop body
endfor
bm1 = toc

function NOP ()
endfunction

tic;
for i = 1:N
  ## Call NOP subfunction
  NOP ();
endfor
bm2 = toc

tic;
for i = 1:N
  ## Call C++ emptyoct function
  emptyoct();
endfor
bm3 = toc


The accompanying emptyoct.cc file is


#include <octave/oct.h>

DEFUN_DLD (emptyoct, args, nargout,
           "emptyoct does nothing, and should be fast")
{
  return ovl (octave_value ());
}


The results were


bm1 = 0.074267
bm2 = 2.2344
bm3 = 1.2721


Even with C++ there is a fair amount of overhead.

Rik <rik5>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #52836:  pprof315.0.pdf added by arb (25KiB - application/pdf)
file #52837:  pprof315.0.txt added by arb (32KiB - text/plain)
file #52822:  bm_fcn_call_overhead.m added by rik5 (253B - text/x-matlab)
file #52823:  emptyoct.cc added by rik5 (153B - text/x-c++src)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by arb (Updated the item)
  • -email is unavailable- added by rik5 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-02-10 arb Attached File- Added pprof315.0.pdf, #52836
        Attached File- Added pprof315.0.txt, #52837
    2022-02-08 rik5 Attached File- Added bm_fcn_call_overhead.m, #52822
        Attached File- Added emptyoct.cc, #52823

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code