Very poor performance with Angle.__str__ and Angle._repr_latex_

The following illustrates very poor performance with Angle.__str__ and Angle._repr_latex_ with arrays:

In [15]: a = Angle(np.ones(1000000), u.deg)

In [16]: %time a.__repr__()
CPU times: user 324 µs, sys: 23 µs, total: 347 µs
Wall time: 332 µs
Out[16]: '<Angle [ 1., 1., 1.,...,  1., 1., 1.] deg>'

In [17]: %time a.__str__()
CPU times: user 22.4 s, sys: 341 ms, total: 22.8 s
Wall time: 23.4 s
Out[17]: "['1d00m00s' '1d00m00s' '1d00m00s' ..., '1d00m00s' '1d00m00s' '1d00m00s']"

In [18]: %time a._repr_latex_()
CPU times: user 22.6 s, sys: 436 ms, total: 23.1 s
Wall time: 23.7 s
Out[18]: '[$1^\\circ00{}^\\prime00{}^{\\prime\\prime}$\n $1^\\circ00{}^\\prime00{}^{\\prime\\prime}$\n $1^\\circ00{}^\\prime00{}^{\\prime\\prime}$ ...,\n $1^\\circ00{}^\\prime00{}^{\\prime\\prime}$\n $1^\\circ00{}^\\prime00{}^{\\prime\\prime}$\n $1^\\circ00{}^\\prime00{}^{\\prime\\prime}$]'

This poor performance is unnecessary since only a few items are returned in the strings, and the rest is ...

This is not an issue with Quantity or Distance, but does percolate up to e.g. SkyCoord I think.

[mhvk]

It seems clear that it is representing all the items – the solution likely is to pass on our own formatter to arrayprint - then the numpy machinery will take care of calling it only for those elements that are actually shown.

[mhvk]

Great! I think no additional tests are needed - this would be a performance label. We do want this in the benchmarks, but that is a different repo (maybe @astrofrog can advice)