このウィッシュリストリクエストのきっかけは何ですか?
中規模のデータ テーブルで Jmp がデータ テーブルの更新 (Tables/Update) を完了するまで、長時間待たなければならない場合があります。
更新プラットフォームで設定を編集しているときに、Jmp がすでにスタックしてしまうことがあります。そのとき、コーヒーを飲み、戻ってきて、散歩するのに良い時間だと判断して、戻ってきます。最後にデータを保存した時期によっては、 Jmp セッションを強制終了して、最後に保存したデータから開始する方が早いかどうかを判断してください。それとも、他の作業をして翌日に戻ってくる方が早いでしょう (少し大げさです)。
あるテーブルの何十万もの値を別のテーブルの値と照合するには時間がかかることは明らかです。
しかし、2 つの列をマージすると、1 つの列をマージする場合に比べて 2 倍の時間がかかることに驚きました (*)
マージされる列ごとに照合ステップが再度トリガーされるのでしょうか? それとも、実際に値の並べ替えに非常に時間がかかるのでしょうか?
多くの場合、ソース テーブルに一意の識別子がありません。単一の一致値が列内に複数回表示され、マージされる列にも同じ値が含まれます。 この場合、最初に一致した値がターゲット データ テーブルに入力され、次に 2 番目の値に置き換えられるかどうかが疑問です...
これは、ソース テーブルで最後に一致する値を検索し、この値を挿入するだけで高速化できます。
アップデート プラットフォームの大きな欠点:
それでは始まります列を追加すると列を置き換えるすべてがアクティブ化されました。
たとえばテーブルに 100 列がある場合、すべての列がプレビュー ウィンドウに追加されるまでに時間がかかります。
そして、私は愚かですが、一致する列を定義することから始めることがよくあります。これにより、実際に追加したい (1 ～ 2) 列を選択できるようになるまで、再び長い散歩を続けることができます。テーブル。
テーブルが大きすぎる場合にプレビューを無効にする機能があります。
しかし、この関数はテーブルの長さをチェックするだけで、列の数はチェックしないのではないかと心配しています。
それとも閾値が大きすぎるのでしょうか？
あなたの経験を共有してください - プレビュータブの更新後、Jmp セッションが再び戻るまでにどれくらいの頻度で時間を埋める必要がありましたか。
もう一つの問題はリコールボタンです
(ここで取り上げられています: https://community.jmp.com/t5/JMP-Wish-List/Disable-Preview-while-filling-the-GUI-via-Recall/idi-p/632362 ）
「Recall」をクリックすると、「Update」メニューに保存された設定が表示されます。また、GUI 設定を変更するたびに「プレビュー」タブが更新されるようです。
したがって、大きなデータ テーブルを結合したい場合は、たとえ 1 つの列を追加したいだけであっても、プレビューを無効にする前に [Recall ...] を押す必要はありません。
改善してほしいことは何ですか?
テーブル/更新のパフォーマンスを改善していただけますか。
この考え方がなぜ重要なのでしょうか?
Tables/Update は素晴らしい機能です。 「プレビュー」タブは驚くほど便利なので、これなしで作業したくありません。
しかし、私は妄想を抱き始めています - 次回データテーブルに列を追加しようとするとき、どれくらい時間がかかるのでしょう。
