octave-maintainers
[Top][All Lists]
Advanced

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

Re: Hotspot identification


From: Rik
Subject: Re: Hotspot identification
Date: Tue, 13 Aug 2019 13:31:54 -0700

On 08/13/2019 11:51 AM, John W. Eaton wrote:
> On 8/13/19 2:09 PM, Rik wrote:
>
>> 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.
>
> Function lookup is slow.  We have to check for overloaded functions. See
> fcn_info::fcn_info_rep::xfind in fcn-info.cc for all the things we look
> for before finding a built-in function.  Is there some better way to do
> it?  For example, is there a way to cache a previous lookup and not have
> to search again if we know that the load path has not changed and no new
> overloaded functions could possibly be found?

I think this is something useful to look at.  From the longitudinal
benchmarking, there was a step change loss of performance from the 3.8.X
series to 4.0.X series.  Looking at the NEWS file for 4.0.0, that release
featured the addition of a Qt-based GUI and classdef OO programming. 
Running today with --no-gui-libs and --no-gui shows very little difference
so I don't think the slowdown is because of the GUI.  That would leave
classdef as a large architectural change capable of a 2X slowdown.

I tried quick test by commenting out the classdef section of
fcn_info::fcn_info_rep::xfind.  It was meaningful, runtime went from 14 s
to 13 s, but at ~7% is no where near large enough to explain the complete
slowdown.  Commenting out the code for packages saved an additional 0.75 s
which is nice, but also not stupendous.

--Rik



reply via email to

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