astropy: SkyCoord.separation is slow due to unneeded frame transform

SkyCoord.separation() takes 22 milliseconds, compared to 4.5 milliseconds for Skycoord.position_angle(). This is the timing for two points in the same coordinate system.

The difference in speed is due to the fact that position_angle() checks whether the coordinate systems are the same, while separation() always does a transformation. Since the most common use-case is to have all of the points be in the same coordinate system, this is extremely wasteful.

The code at sky_coordinate.py:1060:position_angle() and sky_coordinate.py:677:separation() should be identical, since they both serve the same function.

(Neither is fast, largely due #5698 . separation() calls FRAME_ATTR_NAMES_SET() 22 times causing 2717 getattr() calls).

Other comments: I don’t know why the various methods have their own import statements, e.g. sky_coordinate.py:392. It probably is a minimal speed-up to put them all at the top, but it may be a stylistic convention in this project.

The following are possible enhancements (Should they go in a separate issue? Do they already exist in some other library?): I would also like to suggest a single function that returns both separation and posang (because that is something commonly desired).

Also useful would be a function that takes a separation and posang to produce a new point. (My particular use is triangulation from the InterPlanetary Network (IPN) that does timing-base localization of gamma ray bursts. Other uses include drawing field-of-view circles and finding the midpoint between two points.)

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 20 (20 by maintainers)

Commits related to this issue

Most upvoted comments

Since the issue of performance for separation is coming up again, there were similar discussions previously and I argued that we should support a very fast cythonized version that accepts only floats. I still believe this. See https://github.com/astropy/astropy/issues/3908#issuecomment-176782129.