ANTLR4:Java - TokenStreamRewriter getText() 方法的性能問題

Question

我正面臨 ANTLR4-Java TokenStreamRewriter getText() 方法的性能問題。此方法花費的時間太長才能獲得結果。 請檢查我的用例和下面的觀察結果，讓我知道為什么這需要很長時間以及是否可以為此進行任何優化以減少所用時間？

Use Case: I have a Sql text file of size 17 MB, after parsing the file, we are modifying many things in the token stream using TokenStreamRewriter API.. After all the modifications we are using the getText() method of TokenStreamRewriter to get the修改后的文字。 getText() 方法需要 5 多分鍾才能獲取修改后的結果。

我測試了 54MB 的文件大小，這次 getText() 方法花了大約 110 分鍾來獲取修改后的結果。

在我的分析過程中，我發現需要更多時間的方法是： TokenStreamRewriter.reduceToSingleOperationPerIndex()我已經捕獲了該方法的一些執行細節和時間，請參閱以下信息

對於 17MB 文件：

2020-05-14 17:22:33,187 INFO CustomTokenStreamRewriter:392 No of rewrites=164570
2020-05-14 17:22:33,187 INFO CustomTokenStreamRewriter:395 Start Walk Replaces
2020-05-14 17:25:35,874 INFO CustomTokenStreamRewriter:438 End Walk Replaces
2020-05-14 17:25:35,956 INFO CustomTokenStreamRewriter:441 Start Walk Inserts
2020-05-14 17:27:49,723 INFO CustomTokenStreamRewriter:476 End Walk Inserts
2020-05-14 17:27:49,732 INFO CustomTokenStreamRewriter:477 rewrites size after=164570
2020-05-14 17:27:49,732 INFO CustomTokenStreamRewriter:478 Start Walk after
2020-05-14 17:27:49,830 INFO CustomTokenStreamRewriter:488 End Walk after

對於 54MB 文件：

2020-05-14 17:33:29,650 INFO CustomTokenStreamRewriter:392 No of rewrites=493728
2020-05-14 17:33:29,651 INFO CustomTokenStreamRewriter:395 Start Walk Replaces
2020-05-14 18:36:26,294 INFO CustomTokenStreamRewriter:438 End Walk Replaces
2020-05-14 18:36:26,362 INFO CustomTokenStreamRewriter:441 Start Walk Inserts
2020-05-14 19:21:56,112 INFO CustomTokenStreamRewriter:476 End Walk Inserts
2020-05-14 19:21:56,131 INFO CustomTokenStreamRewriter:477 rewrites size after=493728
2020-05-14 19:21:56,132 INFO CustomTokenStreamRewriter:478 Start Walk after
2020-05-14 19:21:56,224 INFO CustomTokenStreamRewriter:488 End Walk after

環境詳細信息：高端 Linux 機器，內存（xmx）值設置為：30 GB

Answer 1

TokenStreamRewriter是懶惰的。 因此，與問題所暗示的相反，您在執行修改后並沒有調用getText來獲取修改后的 text 。 修改僅由 API 排隊。 當您調用getText然后實際工作發生時。

由於這項工作被描述為在 17 兆字節的標記化輸入中“修改許多東西”，因此 5 分鍾聽起來並不太牽強。

我想答案是：您沒有遇到任何getText問題，您只需觀察排隊轉換的總時間。 它們是否可以優化，看起來是另一個問題。