astropy Table 排序性能优化：`get_sortable_arrays()` 机制与 1000 倍加速解析

• 科学计算
• 科研
• 数据分析

导读

astropy.table.Table是天文数据处理中最常用的容器之一，其Table.argsort()与Table.sort()是重排行序的核心接口。本文围绕 astropy 的一项性能优化变更（见 变更记录）展开：新版实现改用col.info.get_sortable_arrays()获取可排序数组，替代旧版通过Table.as_array()构建结构化数组的路径，使包含Time等 mixin 列的多键排序提速超过 1000 倍。读完本文，你将理解get_sortable_arrays()协议的设计思路、Time列双精度儒略日的拆分原理，以及argsort()/sort()底层调用链的完整细节。

一、问题的起点：旧实现为什么慢

在优化之前，Table.argsort()与Table.sort()通过Table.as_array()把整张表构建成一个 numpy 结构化数组，再交给 numpy 统一排序。

这条路径存在两个痛点：

1. 内存开销：as_array()需要对所有列做一次拷贝与 dtype 合并，构建出结构化数组后再排序，多了一步整体数据搬运。
2. mixin 列排序退化：当待排键列包含 mixin 列（如astropy.time.Time）时，结构化数组无法直接承载这类对象，numpy 会退化为逐元素的对象数组（object-array）比较。每次比较都要进入 Python 对象层，调用Time的__lt__等魔术方法，而Time对象本身又包含高精度jd1/jd2双精度分量，比较代价极高。包含Time的多键排序因此常常慢得不可接受。

变更记录的原文明确指出：旧实现“building a structured array viaTable.as_array()”，在包含Time的多键排序中会“falling back to slow object-array comparisons”。这正是本次优化的直接动机。

二、新机制核心：info.get_sortable_arrays()协议

2.1 协议定义：数据列自我描述排序键

优化后的排序逻辑不再由Table统一构造结构化数组，而是问每一列要“如何表示自己的排序顺序”。每列的info对象（DataInfo/MixinInfo体系）需要实现get_sortable_arrays()，返回一个或多个可进行字典序排序的 numpy 数组。

该协议定义于 astropy/utils/data_info.py：

def get_sortable_arrays(self): """Return a list of arrays which can be lexically sorted to represent the order of the parent column. The base method raises NotImplementedError and must be overridden. """ raise NotImplementedError(f"column {self.name} is not sortable")

基类方法直接抛出NotImplementedError，表示“该列没有提供可排序表示”。这带来一个清晰的错误边界：任何不支持该协议的列，在排序时会得到明确的报错，而不是静默走慢速路径。

2.2 普通列：返回列数据本身

对普通的Column（数值、字符串等原生 dtype），排序键就是列数据本身，实现见 astropy/table/column.py：

def get_sortable_arrays(self) -> list[npt.NDArray]: col = self._parent # For a structured array return each of the individual fields in order if col.dtype.names: return [col[name] for name in col.dtype.names] return [self._parent]

值得注意的细节：如果列本身是结构化数组（col.dtype.names非空），则按字段顺序展开为多个数组，保证字典序与字段顺序一致。

2.3Time列：双精度儒略日的无损拆分

Time是本次优化的重头戏。Time内部用jd1+jd2两个 float64 表示高精度儒略日（总精度约 20 位有效数字）。旧实现若要排序，只能退化为对象数组逐元素比较。

新的实现见 astropy/time/core.py：

def get_sortable_arrays(self): parent = self._parent jd1, jd2 = parent.jd1, parent.jd2 jd_approx = jd1 + jd2 jd_remainder = (jd1 - jd_approx) + jd2 return [jd_approx, jd_remainder]

其原理与Time.argsort()（astropy/time/core.py）一致：

• jd_approx = jd1 + jd2得到浮点精度内可表达的最佳近似值；
• jd_remainder = (jd1 - jd_approx) + jd2通过(jd1 - approx)的补偿计算还原被舍去的低阶余量；
• 返回[jd_approx, jd_remainder]两个普通 float 数组，两者做字典序排序即可无损恢复完整 20 位精度的时间顺序。

关键在于：这两个数组都是普通 float64 数组，numpy 可以用纯 C 层快速比较，完全绕开 Python 对象层的Time比较。变更记录特别提到Time.info.get_sortable_arrays()本身也被提速——旧版需要临时构造中间Time对象再做减法，新版直接基于jd1/jd2裸数组做浮点拆分，避免了对象构造开销。

三、argsort()的完整调用链

新版Table.argsort()实现位于 astropy/table/table.py，关键流程如下：

1. 索引捷径：若键列存在表索引（get_index(self, names=keys)非空），直接返回index.sorted_data()，完全绕过排序计算。
2. 收集排序键：遍历每个键列，调用self[key].info.get_sortable_arrays()并把结果平铺进sortable_arrays列表：

sortable_arrays = [] for key in key_names: try: sortable_arrays.extend(self[key].info.get_sortable_arrays()) except NotImplementedError as err: raise TypeError(f"column {key!r} is not sortable") from err

NotImplementedError会被转换为更友好的TypeError并明确指出不可排序的列名。 3.执行排序：

• 若只有一个可排序数组，用np.argsort(sortable_arrays[0], kind=kind)，此时kind（quicksort/mergesort/heapsort/stable）参数生效；
• 若有多个数组，使用np.lexsort(sortable_arrays[::-1])。这里有一个易错点：np.lexsort把最后一个参数当作主排序键，而get_sortable_arrays()返回的数组是从主到次排列的，因此必须先反转顺序。

4. reverse 处理：reverse=True时对结果索引取反idx[::-1]。

四、sort()的原地重排

Table.sort()（astropy/table/table.py）本身不做排序计算，而是复用argsort()：

indexes = self.argsort(keys, kind=kind, reverse=reverse) with self.index_mode("freeze"): for col in self.columns.values(): new_col = col.take(indexes, axis=0) try: col[:] = new_col except Exception: self[col.info.name] = new_col

要点：

• 所有列统一按argsort得到的索引执行col.take(indexes, axis=0)重排，保证行间对齐；
• 排序过程在index_mode("freeze")上下文内进行，避免索引在逐列重排过程中被反复更新；
• 若列支持原地更新（col[:] = new_col）则原位赋值，否则整体替换为新列——这是为兼容不支持原地更新的 mixin 类所做的回退（详见 issue #9553、#9536 的讨论）；
• 当keys=None时，sort()要求表存在索引，否则抛出ValueError("Table sort requires input keys or a table index")。

五、性能收益：数字与适用场景

变更记录给出的量化结论：

• 包含Time的 mixin 列多键排序：提速超过 1000 倍。原因是彻底消除了对象数组比较路径——Time列的每次比较从创建/比较Time对象（内部含两个 float64）变成直接对两个 float64 做 C 层字典序比较；
• 普通多列排序：快数倍。原因是省去了as_array()构建结构化数组的搬运成本，直接对各键列的可排序数组（多数情况下就是列数据自身）做lexsort。

需要说明的是，这些数字来自该变更记录的报告，实际收益与数据规模、键列数量、Time列占比相关；但“避免对象比较 + 减少一次全表拷贝”这两条优化路径的收益方向是明确的。

六、测试验证与回归保护

本次优化有对应的测试覆盖，见 astropy/table/tests/test_operations.py：

• test_argsort_time_column：回归测试 #10823，验证t.argsort("time")与times.argsort()结果一致；
• test_argsort_multiple_keys_with_time_column：回归测试 gh-14942，验证Time与其他键列混合排序（["time", "idx"]与["idx", "time"]两种主次顺序）均得到正确索引，该测试的 docstring 明确记录了“Table.argsort()使用col.info.get_sortable_arrays()使Time等 mixin 列高效正确排序”这一设计意图；
• test_argsort_non_sortable_mixin_raises：验证不实现该协议的列（如SkyCoord）会抛出TypeError: column 'sc' is not sortable。

测试同时覆盖了Table.sort()对已建索引表的排序（test_sort_indexed_table），确保新实现不破坏索引路径。

七、实战使用示例

日常使用中，API 完全不变，无需改代码即可享受性能收益：

from astropy.table import Table from astropy.time import Time t = Table({ "time": Time(["2018-01-01", "2018-01-01", "2017-01-01", "2016-01-01"]), "idx": [1, 0, 1, 0], }) # 多键排序：先按 time，再按 idx；结果索引为 [3, 2, 1, 0] i = t.argsort(["time", "idx"]) # 原地排序，先按 idx 再按 time t.sort(["idx", "time"]) # 多键排序中 kind 参数仅在单数组时生效， # 含 Time 等展开为多数组的列时会用 np.lexsort，kind 被忽略

官方文档对排序用法的说明见 docs/table/modify_table.rst（t.sort('b')、t.sort(['a', 'b'])）。

八、总结

get_sortable_arrays()协议把“如何表示排序键”的决策权从Table下沉到各列类型自身，实现了三层收益：

1. 正确性：Time的双精度儒略日通过近似值 + 余数的双数组拆分得到无损表示，字典序与真实时间序严格一致；
2. 性能：所有排序键最终都是普通 numpy 数组，全程 C 层快速路径，规避对象数组比较，多键排序收益可达千倍量级；
3. 可扩展性：任何新 mixin 类型只需实现info.get_sortable_arrays()即可获得高效排序，未实现者得到明确的TypeError而非静默降级。

对于需要频繁对含时间列的大型表做多键排序的天文数据处理流水线而言，这是性价比极高的一项底层优化——接口零变化，收益直接到账。

• 科学计算
• 科研
• 数据分析