Repository navigation
ConfigNamespace is slow #12504
Description
In investigating some performance issues for #12491 I found that a not-insignificant contributor is the performance of looking up values in ConfigNamespace.
It is actually quite slow if you look at the code, specifically for ConfigItem.__get__, which goes through quite a lot of steps of looking up the correct config object, reading the value from it, checking aliases, validating the value, etc.
This means that if some config option is used in a tight loop or in other common code paths it can be a bit of a drag.
For astropy.io.fits this comes up in particular for header parsing, for which there are a couple of different config options, and these get checked for every single card in a header when parsing its value (not a huge problem if you don't read every card in the header, but if you read a few hundred cards of each header it blows up).
I'm still analyzing exactly how much it contributes to the overall time of parsing headers, but it seems to be a significant component. I have some ideas for fixing this but still experimenting.
Activity
pllim commentedon May 14, 2025
#17461 was reverted in #18144 because it had unintended consequences (#18138).
mhvk commentedon May 14, 2025
From the discussion there, it would seem that storing the values on the config item for speed would still be possible, but one has to have a way to delete them when the main config space is reloaded. This might already be possible if the main config space stored the module which it is the configuration for. Alternatively, a weak reference on the config item to the main configuration would also ensure that once the config item is removed, the value disappears too (though not sure if that would still give a good enough performance boost).
Read the FITS config in Card only where it can change the result
Card: test the value type and card image before reading two config items