有关不同语言的准确率，请参阅DAS 教程 2016中的测试部分。
谷歌数据中心的大型测试（印地语？）
| 引擎 | 总字符错误 | 单词召回错误 | 单词精确度错误 | 运行时间 | CPU 时间* |
|---|---|---|---|---|---|
| Tess 3.04 | 13.9 | 30 | 31.2 | 3.0 | 2.8 |
| Cube | 15.1 | 29.5 | 30.7 | 3.4 | 3.1 |
| Tess+Cube | 11.0 | 24.2 | 25.4 | 5.7 | 5.3 |
| LSTM | 7.6 | 20.9 | 20.8 | 1.5 | 2.5 |
请注意，在上表中，LSTM 在运行时间和 CPU 时间方面都比 Tess 3.04（不添加 Cube）更快！在运行时间上快了 2 倍。
在 HP Z420 上对单个印地语页面进行测试的三个结果的中位数。
| 测试模式 | 实际 | 用户 |
|---|---|---|
| 原始（Cube + Tess） | 7.6 | 7.3 |
| 基本 Tess | 2.9 | 2.6 |
| Cube | 5.4 | 4.9 |
| 带 OpenMP+AVX 的 LSTM | 1.8 | 3.8 |
| 不带 OpenMP 但带 AVX 的 LSTM | 2.7 | 2.4 |
| 不带 OpenMP 但带 SSE 的 LSTM | 3.1 | 2.7 |
| 不带 OpenMP 也不带 SIMD 的 LSTM | 4.6 | 4.1 |
我使用简单截图进行的第一次测试显示 LSTM 的结果明显更好，但需要 16 分钟的 CPU 时间（而不是 9 秒），使用的是 Tesseract 的调试版本（
-O0）。发布版本（-O2）使用 LSTM 需要 17 秒，不使用 LSTM 需要 4 秒，用于同一图像。
调试速度慢是可以预期的。新代码的内存占用量要大得多，因此在调试时速度要慢得多（调试时也会选择关闭 OpenMP）。优化后的构建速度听起来对于基于拉丁语的语言来说是合理的。对于复杂脚本，其运行速度相对于基本 Tesseract 会更快。
参考：https://github.com/tesseract-ocr/tesseract/issues/40