Opened 13 years ago

Closed 13 years ago

#100 closed defect (fixed)

Profiling - use of scan list?

Reported by: MatthewWhiting Owned by: MatthewWhiting
Priority: normal Milestone: Release-2.0
Component: Code base Version: 1.1.10
Severity: normal Keywords:
Cc:

Description

Looking at detailed profiling:

If you look at a single channel of the noise-free WALLABY test cube with a threshold at zero, it takes quite a while to run. A lot of this time is spent sorting the scan list.

It should be possible to remove the need for sorting, but this may have implications for other functions (that might assume the scan list is ordered by y-value).

Could also look at lutz_detect, as it may be possible to simplify the adding of pixels - in fact, we should be making use of scans here anyway.

Also, look at addScan - can't we just add a scan in without doing it pixel-by-pixel? Not that this is used outside of adding existing detections though.

Change History (2)

comment:1 Changed 13 years ago by MatthewWhiting

Status: newassigned

I've removed the need for sorting the scan list each time - it now only gets sorted when the object is printed. There was, I think, just one function that assumed things were ordered, and this was fixed with the use of a couple of iterator loops.

There probably is a need for an improved addScan, but it would need additional checks to pull up subsequently-merged scans (the same case as with the full object merger case).

Something seems to have broken on the last changes, though, so need to track that down. For some reason the parameter-calculation function fails with finding the flux array uninitialised...

comment:2 Changed 13 years ago by MatthewWhiting

Resolution: fixed
Status: assignedclosed

This seems to be fixed by the changes flowing from [102]. Running that test now (using parset input_sky) runs quickly with no problems.

Closing.

Note: See TracTickets for help on using tickets.