You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This class is currently only used in the most-likely-to-be-removed (see parent issue) MonochromeTraceCurve and in some test cases. However, there is an old TODO-item (I'm seeing that TODO list for the first time...) that mentions the following:
Remove dependency on astropy HDU objects
WHY: They are slow. Too many internal checks on the header keywords. Factor of 10x speed increase when using ScopeSim's interal "PoorMansHeader" object
WHAT: Expand PoorMansHeader to cover all use cases, add minimal units checks, replace all occurences of astropy HDU objects
I'm now wondering whether this is actually (still) relevant. I think in most cases the performance impact of the astropy HDU header is minimal, and it does offer some interoperability advantages. However, I haven't actually done any profiling on this to say with any certainty whether this has a relevance in practice. If it indeed does, I'm open to the idea of reviving the PoorMansHeader and using it more internally. If not, I suggest removing the class and just sticking with astropy's solution.
The text was updated successfully, but these errors were encountered:
This class is currently only used in the most-likely-to-be-removed (see parent issue)
MonochromeTraceCurve
and in some test cases. However, there is an old TODO-item (I'm seeing that TODO list for the first time...) that mentions the following:I'm now wondering whether this is actually (still) relevant. I think in most cases the performance impact of the astropy HDU header is minimal, and it does offer some interoperability advantages. However, I haven't actually done any profiling on this to say with any certainty whether this has a relevance in practice. If it indeed does, I'm open to the idea of reviving the
PoorMansHeader
and using it more internally. If not, I suggest removing the class and just sticking with astropy's solution.The text was updated successfully, but these errors were encountered: