<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />你好夥伴JMPers。 以為我會和你分享一些我的JSL性能改進故事。 如果你使用WORDS來解析很長的字符串（> 200,000個字符），這將有所幫助。
我在JSL中遇到了一些性能問題。 我追踪它以減慢WORDS函數的性能，因為它很長。 WORDS函數使用空格或提供的分隔符將字符串解析為列表。 通常這個函數非常快，但是對於大約200,000個字符的字符串，它開始變慢。 是的我有很長很長的字符串。 這是一個表現圖：
所以我寫了一個更好的捕鼠器。 事實上我從圖中可以看到兩個捕鼠器。 第一個（MYWORDS1）使用OPEN將文本字符串打開到數據集中。 第二個（MYWORDS2）將數據切割成大約100,000字節的塊並在塊上運行WORDS。 兩者都具有相對於WORDS的優異性能，在較高的字符數下。
雖然MYWORDS1功能略好一些，但如果文本有回車符和換行符則會有問題，所以我可能會將MYWORDS2用於生產用途。
MYWORDS1中使用的技術有很多可能性！感謝Peter Wiebe最初使用OPEN的想法，以及審查並改進我的代碼。 這是一個簡短的示例，演示如何將文本字符串打開到數據集中，將每個分隔的字符串解析為單獨的行：
big_string = “這是一個由空格分隔的示例字符串” ;
tmpdt = 打開 （ char to blob （ “WordColumn” || “” || big_string ） ，文本 ，
行結束 （ 其他 ） ， eolother （ “” ） ， endoffield （ 標籤 ） ，無形 ） ;
BTW這些結果是在32位XP機器上使用JMP 9.0.2，配備3 GB內存和i5-2520M CPU 2.50GHz處理器。 我已經使用JMP 9和JMP 10 beta測試了Windows 7下的功能，結果具有可比性。
我附上了函數代碼和一些測試代碼。
請享用！
彼得
