Opened 9 years ago

Last modified 8 years ago

#467 new task

Investigate performance inplications of current ArbitrarilyDiscretizedFunction implementation

Reported by: Kevin Milner Owned by: Kevin Milner
Priority: major Milestone:
Component: sha Version:
Keywords: Cc:


The current ArbitrarilyDiscretizedFunction? implementation uses a list of Point2D instances, which may not be efficient for hazard calculations

Change History (2)

comment:1 Changed 9 years ago by Kevin Milner

For all benchmarks I will be calculating 8 UCERF3 hazard curves in a single thread. Here are some initial test results:

With arbitrarily discretized functions: 92 s
With arb discr function passed in, fixed X function used internally: 87 s
With fixed X function passed in and used interally: 84 s

So this simple change can save over 6 % off of the calculation speed. The fixed X values class I'm using right now is, which is a mostly complete implementation. This doesn't include investigation of the constant creation/destruction of Point2D values used in the DiscretizedFunction? interface.

comment:2 Changed 8 years ago by Peter Powers

Notes on LightFixedXFunction:

The drop in substitution of this into HazardCurveCalculator? broke code that (probably shouldn't have been) dependent on the write through ability of the Point2Ds returned by ArbDiscrFuncs? iterator(). I've made appropriate fixes, but it should probably be documented that the Point2D iterators are not write-safe.

The documentation states that the function x-values can not be changed, yet the getXValues method returns the internal mutable array. Is there something wrong with using the xValues and yValues methods of XY_DataSet instead (that return immutable lists)?

Note: See TracTickets for help on using tickets.