請參閱DAS Tutorial 2016中的測試章節，以了解不同語言的準確率。
Google 資料中心的大型測試（印地語？）
| 引擎 | 總字元錯誤 | 單字召回錯誤 | 單字精確度錯誤 | 實際時間 | 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 |
| 完全不使用 SIMD 的 LSTM | 4.6 | 4.1 |
我第一次使用簡單的螢幕截圖進行測試，LSTM 給出了明顯更好的結果，但在 Tesseract 的偵錯版本（
-O0）中需要 16 分鐘的 CPU 時間（而不是 9 秒）。發佈版本（-O2）對於相同的影像，使用 LSTM 需要 17 秒，不使用則需要 4 秒。
偵錯版本的速度較慢是預料之中的。新程式碼更耗記憶體，因此在偵錯模式下會慢很多（偵錯時也會選擇關閉 OpenMP）。對於拉丁語系的語言來說，最佳化建置的速度聽起來是合理的。相較於基本 Tesseract，複雜的文字將會執行得更快。
參考：https://github.com/tesseract-ocr/tesseract/issues/40