SExtractor - SourceXtractor++ very naive speed comparison #539
Replies: 4 comments
-
Although SE++ is expected to run slower than SE2, the factor of 10 you find is quite extreme. Maybe you ran SE2 repeatedly a few times and the input data was mem-mapped by the OS? For SE++ the performance depends strongly on which output properties you ask via My rather personal take on SE2 vs. SE++ is:
|
Beta Was this translation helpful? Give feedback.
-
Thanks for your opinion, very much appreciated. This was with All values were left to default, except for Setting |
Beta Was this translation helpful? Give feedback.
-
To give a bit more context, SE2 uses a custom made FITS I/O library and the entire program was heavily optimized for a quick throughput of problems such as yours. In SE++ we use CFITSIO and the optimization is for flexible model fitting (which means way more processing per source) on multi-band and multi-scale data. Note that your image data is rather small (for modern data). It might be that SE++ needs more resources to setup the processing and things are more comparable going to larger arrays, but we really do not know. |
Beta Was this translation helpful? Give feedback.
-
Just to complete what Martin said. SX++ is much slower than SE when run on small images with a few sources, because there is much more going on at startup. On large images with many sources, you can speed up processing quite significantly by adding, e.g, the command line arguments |
Beta Was this translation helpful? Give feedback.
-
I just ran a very naive speed test to compare SExtractor with SourceXtractor++ on a 2230² pixels image with 2025 sources above a 10 σ background: both source finders find exactly 2025 sources, but SExtractor is more than ten times faster: 0.238s for SExtractor vs. 3.124s for SourceXtractor++ .
Is this expected or can I perhaps switch off some overhead of SourceXtractor++ to make the comparison fairer?
Beta Was this translation helpful? Give feedback.
All reactions