<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />JMPersさん、こんにちは。 私のJSLパフォーマンス改善ストーリーをあなたと共有したいと思います。 非常に長い文字列（> 200,000文字）を解析するためにWORDSを使用しているなら、これは役に立ちます。
私はJSLでパフォーマンス上の問題を抱えていました。 本当に長い文字列では、WORDS関数のパフォーマンスが低下したためです。 WORDS関数は、スペースまたは指定された区切り文字を使用して文字列をリストに解析します。 通常、この関数はかなり高速ですが、長さが約200,000文字の文字列では遅くなり始めます。 はい私はそんなに長い文字列を持っています。 これがパフォーマンスのグラフです。
だから私はより良いネズミ捕りを書いた。 あなたがグラフからわかるように、実際に私は2つのネズミ捕りを書いた。 最初のもの（MYWORDS1）はOPENを使用してテキスト文字列をデータセットに開きます。 2番目のもの（MYWORDS2）は、データを約100,000バイトのチャンクに切り取り、そのチャンクに対してWORDSを実行します。 どちらも、文字数が多いほど、WORDSと比べて優れたパフォーマンスを発揮します。
MYWORDS1関数は多少優れていますが、テキストにキャリッジリターンとラインフィードがある場合は問題があります。そのため、本番用にはおそらくMYWORDS2を使用します。
MYWORDS 1で使用されているテクニックにはたくさんの可能性があります。OPENを使用するという当初の考え、そしてコードを見直して改善してくれたPeter Wiebeに感謝します。 これは、テキスト文字列をデータセットに開き、区切られた各文字列を別々の行に解析する方法を示す簡単な例です。
big_string = 「これはスペースで区切られたサンプル文字列です」 ;
tmpdt = 開いた （ BLOBにchar （ 「WordColumn」 || 「」 || big_string ） 、テキスト 、
エンドライン （ その他の ） 、暑い （ 「」 ） 、エンドフィールド （ タブ ） 、見えない ） ;
ところで、これらの結果は3 GBのRAMとi5-2520M CPU 2.50GHzプロセッサを搭載した32ビットXPマシン上のJMP 9.0.2でのものでした。 Windows 7でJMP 9とJMP 10ベータ版を使用して機能をテストしましたが、結果は同等でした。
関数のコードといくつかのテストコードを添付しました。
楽しい！
ピーター
