当我对使用新的ish（7.4）表表达式在内部表上执行搜索的两种不同方法进行快速性能测试时，我得到了一个值得在博客上讨论的惊喜。

我的场景涉及到内部表搜索，其中值会丢失很多时间。意外的结果是，当找不到行时，使用带异常的表表达式平均比所有其他查找方法慢十倍，包括使用SY-SUBRC的老式READ table，在表格中找到一个条目真是妙不可言。我有一个包含字段"ID"的表。因此，大数据软件，可以使用表表达式（方括号中的位）重写下面的读取表：

如果找不到匹配的条目，您需要捕获异常：

另一种方法是使用值构造函数表达式，在其中可以添加关键字OPTIONAL（或DEFAULT）来初始化任何未找到的值。

这种特殊的值用法可能看起来有点尴尬。我的意思是，既然你可以写x=y，为什么还要用x=VALUE（y）？值构造函数在这里的唯一用途是可选位，它允许我们除去例外。

当我在处理一个性能敏感的组件时，我测试了它，电梯物联网，看看什么性能最好。

为了完整性，除了雅克·诺姆西（Jacques Nomssi）、奎恩·多安·曼（Quynh Doan Manh）和乌韦·费泽（Uwe Fetzer）在评论中的建议之外，我还添加了一些在表中查找条目的其他方法：

可靠的读取表…带键，带或不带任何字段行\u存在（）ASSIGN itab[…]–它（奇怪地）设置SY-SUBRC而不是生成异常REF#（），而不是VALUE#（）。

我在7.50 HANA系统上测试了一百万次失败的查找。以下是以微秒为单位的结果：

我根本没有预料到最后一个。

因此，这里给我带来的好处是TRY-CATCH可能更容易阅读，但不应该在性能敏感的代码中使用，除非您希望在大多数情况下都能找到值时间。我很高兴为可读性牺牲一点性能，但这是一个重大的影响。

我怀疑这适用于一般的CATCH块，但这是另一天的另一个分析。

为了进行比较，我也重新运行了相同的，立返利，但这次有一个确实存在的查找值。发生了两件事：

例外不再是一种影响（意料之中）在我的场景中，行\u exists（）成为了一个糟糕的选择，因为我们需要加倍搜索以同时读取记录：

如果您不需要数据，行\u exists（）是最快的。如果性能是第一优先级，并且您需要数据，那么读取表是最快的。对于紧凑和/或可读代码，请使用表表达式。（是的，我知道，‘new’ABAP可以用来使代码更可读或更神秘，但这是另一个讨论）带表表达式的TRY-CATCH是构造代码的有用方法（例如，大数据对比，对多个表达式使用单个CATCH处理程序），但要注意组件的预期故障率和性能关键性。如果我们在短时间内谈论的内容少于数千个，那么您可以放心地忽略其影响。

更新：

经过几次评论和建议，im即时通讯云，我将我的测试程序上传到GitHub的abap\u itab\u perf

它只是一个快速的n-dirty最初只用于比较两个选项，只是作为替代方案的复制/粘贴。您可以随意使用它，甚至通过GitHub发回任何更新。