Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What to do with PoorMansHeader? #567

Open
teutoburg opened this issue Feb 12, 2025 · 0 comments
Open

What to do with PoorMansHeader? #567

teutoburg opened this issue Feb 12, 2025 · 0 comments
Assignees

Comments

@teutoburg
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 📋 Backlog
Development

No branches or pull requests

2 participants