-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Fitting of CompoundModel is slow #8338
Comments
Can you supply the model you used? I've been looking at this particular call very recently in my rework of modeling, just out of chance. There isn't that much to it so I'm surprised that recursive call takes that much time, but I'd like to look into it. |
The model is created by photutils, it is a sum (https://github.com/astropy/photutils/blob/master/photutils/psf/utils.py#L109) of IntegratedGaussianPRF (https://github.com/astropy/photutils/blob/master/photutils/psf/models.py#L795). I wanted to try if I can reproduce with a sum of astropy Gaussian2D, but did not have the time yet. |
Here is a reproduction directly with astropy, just adding Gaussian2D models: https://gist.github.com/saimn/cea2d1dff0ed933525efb743553a80ad |
Ping @larrybradley in case you missed this, since this makes photutils' psf photometry nearly impossible to use, unless stars have no close neighbors ;). |
I just confirmed the slowness with just Gaussian2D models a few minutes before you posted that. If it is any consolation, the new version of modeling (won't be out until the next major version of astropy unfortunately) doesn't suffer this problem. The time for 25 Gaussian2D components in that only takes 4.5 ms. I'm still waiting for the other to finish... |
Just finished. 36 seconds (I used timeit so it ran it 7 times). What, a factor of 8,000 is unacceptable? |
I'll see if I can understand why the current one behaves this way and if there is any simple fix. |
@saimn Yes, I noticed. :) I'm hope the new modeling updates will be a big improvement. |
Fitting ePSFs to ~1000 sources took me about 20 minutes. A factor of 8000 improvement would bring that down to 0.15 seconds, which is certainly acceptable. 😄 |
Great for the new version! |
The problem was tracked down to util.py ExpressionTree property inputs_map. This only shows up when there are more than one input coordinate and results in a doubling of calls to this property at every level of the expression tree. At 24 levels that basically becomes something on the order of 2**24 calls, a moderately substantial number, even for a simple routine ;-) I have a fix for this that I will later submit. I'll need to test it more thoroughly. |
@perrygreenfield I assume you didn't mean to close the issue. |
Right. They should make that button harder to get to :-) |
I'm playing with some photometry computation with photutils, which is horribly slow, and this appears to be because of
astropy.modeling
trying to know if the model has some units. From what I understand with the traceback below (after interrupting the process), accessingself.input_units
triggers a recursive lookup that takes a lot of time, exponentially increasing with the number of sources in the CompoundModel. And this for a model that has no units, and for each iteration if I get it correctly.https://github.com/astropy/astropy/blob/master/astropy/modeling/core.py#L2861
I cannot provide reliable timing for now as it takes just too long, but I measured one call to
prepare_units
to 17sec, with a model with 24 (gaussian) sources. Replacing._validate_input_units
by a no-op method makes thing work, fitting the 24 sources group in 5 seconds (I will try to get the timing without this tomorrow).The text was updated successfully, but these errors were encountered: