搜尋凍結

Question

有其他幾篇帖子提到 CPU，但我不確定我的問題是否直接相關，所以我開了一個新主題。如果我應該回覆之前的帖子，請見諒。
我一直覺得 PT8 有點慢，但我同時開啟了很多資源，所以我想這可能就是這樣。我原本希望 PT9 會更快，但結果還是一樣。我通常會開啟 Chrome，但即使不開啟，速度似乎也沒有變快。有些搜尋即使結果很多也很快（例如「reckon」在不到一秒內找到 275 個結果），但有些搜尋非常慢，甚至根本沒有結果（例如「. (see」跑了幾分鐘後，我不得不使用工作管理員關閉 PT，這發生了好幾次）。當這種情況發生時，CPU 似乎幾乎達到 100%。

image666×593 27.1 KB

我使用的是 Windows 10 (1903)，擁有 16GB RAM。處理器（如果這對任何人有意義的話）是：

有什麼想法可以加快 PT 的一般速度，或讓所有搜尋都能正常運作嗎？

機器翻譯自 English 顯示原文

Answer 1

請透過 Help > Give feedback 回報這類問題。在得體的電腦上，任何搜尋都不應該花超過幾秒鐘。
這類問題通常源於我們內部建立正則表達式來執行搜尋，並且有幾種情況是生成的正則表達式與負向先行斷言（negative look-behind）產生無限循環（稱為 災難性回溯，且永遠不會結束）。看起來你發現了這個問題的另一個案例。

機器翻譯自 English 顯示原文

Comments

已回報

機器翻譯自 English 顯示原文

---

你連結到了 RegexBuddy 創作者的文件。我經常使用它來幫助我構建良好的正則表達式，但我知道有不同類型的 RegEx，它們有不同的語法。RegexBuddy 允許在適當的類型之間切換，但我不總是確定該選擇哪一個。

有人能告訴我以下位置使用的正則表達式類型在「RegexBuddy」中的正確選擇嗎：

• Paratext 9 Find/Replace
• Paratext 9 RegexPal
• Changes.txt, FinalChanges.txt, PrintDraftChanges.txt, DBLchanges.txt 等
• SIL Encoding Converters
• InDesign 中的 Grep Styles

機器翻譯自 English 顯示原文

Answer 2

嗯，你確實找到了開發人員測試用的最佳搜尋表達式。我剛在一個完整的聖經專案中搜尋了
. (see
並開始計時。我在 4 分半後放棄並取消了搜尋。我有一顆第 10 代 i7 處理器，6 核心和 16 Gig RAM，所以這會讓任何人的電腦都癱瘓。

我剛試了 9.1，情況沒有更好。

機器翻譯自 English 顯示原文

Comments

如果你取消勾選「忽略空白差異」方塊（在 More>> 下方），會有差別嗎？

這其實不是一個解決方案，因為你可能確實想要匹配一個或多個空格，但這可能提供線索，說明是什麼導致了減速。

機器翻譯自 English 顯示原文

---

12 秒。看來我們在使用「忽略空白差異」選項時有問題。

機器翻譯自 English 顯示原文

Answer 3

我只能回答 PT9 Find/Replace、RegexPal、PrintDraftChanges.txt 和 DBLchanges.txt。它們都使用 .Net 內建的正則表達式引擎：C# (.NET 2.0–4.8 & .NET Core 1.0–3.0)。

機器翻譯自 English 顯示原文

Comments

在這段無害的文字中隱藏著一件非常重要的事情。你是說 Paratext 9 RegExPal 現在使用與 Paratext Find/Replace 相同的正則表達式類型嗎？這非常重大且令人歡迎，儘管我必須修改我的正則表達式庫。完全值得。

機器翻譯自 English 顯示原文

---

Shegnada:

你是說 Paratext 9 RegExPal 現在使用與 Paratext Find/Replace 相同的正則表達式類型嗎？

我認為是的。這有點複雜。

在 Paratext 7.x 中，RegExPal 使用 Python 來執行正則表達式搜尋。為了簡化 Paratext 8 中的程式碼，我們改為使用 IronPython，這是一種使用 .Net 實現的 Python。查看 IronPython 的原始碼，似乎它使用 .Net RE 引擎來實現 Python 正則表達式。

然而，由於普通 Python 和 .Net 的正則表達式實現之間存在細微差異，我猜測 IronPython 必須對表達式進行一些小的調整，以使其與 .Net 的實現相容。我不 100% 確定它是否對 RE 進行了一些處理以使其運作，或者這些更改是否可能使 IronPython 與普通 .Net 略有不同。

機器翻譯自 English 顯示原文

---

我要指出，在 Find 中，換行符被忽略，因此你無法搜尋類似 \\s .* 的內容來找到章節標題。即使你包含 (?-s)，換行符仍被忽略。

機器翻譯自 English 顯示原文

---

anon848905，你在 Find 對話框中提到的限制是有問題的。近幾個月來，我與用戶分享的許多表達式不再有效（如果它們在 pt9 中），因為這種「忽略換行符」的現實情況。我經常使用負向字符類來表示「直到……」……最常見的是

• 直到新行：[^\r]+
• 直到下一個標記（在同一行）[^\r\\]+

這些表達式（或技術）用於將搜尋限制在上下文中，現在不再有效。

我要再次提到，這對那些不想進入 RegexPal 的用戶，或需要在 Paratext 中逐一修復大量問題的用戶來說是有問題的。

機器翻譯自 English 顯示原文

---

你可以做的一件事是，將複雜的 RegEx Find 導出 RegExPal 列表，用文字編輯器稍作調整，然後發送給他們在 List Window 中開啟。

機器翻譯自 English 顯示原文