Re: テーブル/更新の高速化まず第一に、プログレスバーはユーザーを助けることができます
...少し: Jmp はクラッシュしていませんが、バックグラウンドで何かを実行していることを理解するためです。
Re: テーブル/更新の高速化これを試してみてください - 生徒 40 人、N x:
Names Default to Here(1);
// adjust the size and check// +1 means: data table size x 2// ... and update time x 4
mySize=12;
dt0 = Open( "$SAMPLE_DATA/Big Class.jmp" );
increaseSize= Function({dt,cycles},
for(i=1,i<=cycles,i++,
dt << Concatenate(dt, Append to first table))
);
increaseSize(dt0,mySize);
show(nrows (dt0));
dt2 = subset(dt0);
//if you are brave, enable this:
/*for (i=1,i<5,i++,
dt2 << new column("new", set each value (random uniform()))
);*/
//generate a list of columns which should be added
Cols = dt2 << get column names();
remove from (cols, {1,2,3} );
dt0 << Delete Columns( :height, :weight );
t1=hptime();
Eval(Eval Expr(dt0 << Update(
With( dt2 ),
Match Columns( :name = :name, :sex = :sex ),
Add Columns from Update Table(
Expr(Cols)
),
Replace Columns in Main Table( None )
)));
show((hptime()-t1)/1000000); // on my notebook: ~ 15s per column
close(dt0, noSave);
close(dt2, noSave);Re: テーブル/更新の高速化興味深いことに、
remove from (cols, {1,2,3} );テーブル/更新にはさらに 10 秒かかります。
行のマッチングは追加された各列に対してのみ行われるわけではないようです。
すでに存在する列に対してもある程度行われます。
Re: テーブル/更新の高速化置き換えることができるのは、テーブル/更新ユーザー定義のプラットフォームを使用します。
- 列の追加/置換を次のように設定します。選択済み/なし（それ以外のすべて/すべて) --> プレビューで評価される列が少なくなります
- ユーザー定義のボタンOK（高速）設定を変換した後にテーブル/結合をトリガーできます
UpdateHS()経由
Names Default to Here(1);
dt = Current Data Table();
If(isempty(dt) | N rows(dt )==0, stop());
Try( myDTUpdate << close window() );
myDTUpdate = New Window( "Update - high speed", dt << update() );
myDTUpdate[Lineup Box( 1 )] << Prepend( mb = MouseBox( Button Box( "OK (HS)", updateHS() ) ) );
mb << settooltip( "high speed via Tables/join" );
//DtUpdateHS:myDTUpdate["Preview", CheckboxBox( 1 )] << set( 1, 0 );
myDTUpdate["Add Columns from Update Table", Radio Box( 1 )] << set( 3 );
myDTUpdate["Replace Columns in Main Table", Radio Box( 1 )] << set( 2 );
Re: テーブル/更新の高速化UPDATE が独自の関数を使用しなければ、大幅な改善が達成できるようです
...ただし、バックグラウンドで JOIN をトリガーしただけです。
Re: テーブル/更新の高速化Tables/Join と Tables/Update の速度の違いに関して、Jmp Support (TS-00044631) から次のようなフィードバックを受けました。
設計上、複数の一致がある場合、Update と Join は異なる動作を行います。[...] Join は初め一致するため、一致するものが見つかるとすぐに処理が完了します。
[...] これらの一致すべてを介して [検索] を更新し、それぞれを適用し、最後の一つスティック。 *)
これは、データのコピーが多数あるため、上記の特殊なケースで大きなタイミングの違いが生じることを説明しています。
したがって、一意でない値と多くの列を含むテーブルがある場合は、Update を使用するときは注意してください。
一方、Jmp が次の存在をチェックすると、この問題は簡単に修正されます。一意でない値と多数の列プレビューを計算する前に:)
*) Tables/Join と Tables/Update の違いは、Jmp Support の次の例でわかりやすく示されています。
注目してください。参加しましたテーブルにはすべてが揃っています1はcol2にありますが、更新しましたテーブルにはすべてが揃っています3はcol2にあります。
dt0 = New Table( "MyTable",
Add Rows( 3 ),
New Column( "col1",
Character, "Nominal",
Set Values({"a", "a", "a"})
),
New Column( "col2",
Numeric,
"Continuous",
Set Values([1, 2, 3])
)
);
dt2 = subset( dt0 );
Cols = dt2 << get column names();
Remove From( cols, {1} );
dt0 << Delete Columns( :col2 );
Eval(Eval Expr(dt0 << Join(
With( dt2 ),
Select( :col1 ),
SelectWith(Expr( Cols) ),
By Matching Columns( :col1 = :col1 ),
Drop multiples( 0, 1 ),
Preserve main table order( 1 ),
)));
Eval(
Eval Expr(
dt0 << Update(
With( dt2 ),
Match Columns( :col1 = :col1 ),
Add Columns from Update Table( Expr( Cols ) ),
Replace Columns in Main Table( None )
)
)
);Re: テーブル/更新の高速化
@ほぎ書きました：
しかし、この関数はテーブルの長さをチェックするだけで、列の数はチェックしないのではないかと心配しています。
実はTables/Updateで列数をチェックしているようです
- 列が 100 を超える場合、自動更新は無効になります。
しかし、Jmpはメインテーブルの行数/列数をチェックしているだけのようです
2番目のテーブルのものではありません。
したがって、メインテーブルの列数が大きすぎる場合、プレビューは無効になります。ただし、列数 (メインテーブル) は速度には影響しません。
Names Default to Here(1);
// adjust the size and check// +1 means: data table size x 2//
mySize1=7;
dt0 = Open( "$SAMPLE_DATA/Big Class.jmp" );
new column ("one", set each value(1));
increaseSize= Function({dt,cycles},
for(i=1,i<=cycles,i++,
dt << Concatenate(dt, Append to first table))
);
increaseSize(dt0,mySize1);
numberRows0 = Nrows(dt0);
dt2 = dt0 << Subset( All rows, columns( :name, :age ) );
for (i=1,i<1000,i++,
dt2 << new column("new", set each value (random uniform()))
);
numberRows2 = Nrows(dt2);
dt2Name = dt2 << get name();
New Column( "Rank", Formula( Col Rank( Row(), :name ) ));
Try(updateWindow << close window());
updateWindow = New window("are you brave?",
dt 0 << update()
);
updateWindow[Text Box(1)] << background color (Orange) << text color (white )<< set font ("Arial Black", 10)
<< set text("The tables have <10k rows. \!nBut the second table has > 1000 columns. \!nSo I deactivated the preview for you.\!nIf you have some time, activate it again ...");
updateWindow["Preview", CheckboxBox( 1 )] << set( 1, 0 );
updateWindow[ListBoxBox( 1 )] << set selected (loc(updateWindow[ListBoxBox( 1 )] <<GET items=""></GET>
編集：
場合によっては、追加の一致条件 (ソース テーブル内のランクなど) を追加する努力が価値がある場合があります。
これにより、一致の数が減り、プレビューと実際の更新が大幅に高速化されます。
テーブル/更新の高速化このウィッシュリストのリクエストのきっかけは何ですか?
☐ クールな新機能
☑ 多くのユーザーに役立つ可能性があります!
☑ 「バグ」を除去する
☐ あれば便利
☐ 誰もそれを必要としない
#私のトップ10_2023
(これか、 テーブル結合: メインテーブルを更新するオプションのいずれか)
回避策がある -> もう必要ありません
Tables Update は、列をデータ テーブルにマージしたり、別のデータ テーブルのデータで列を更新したりするために使用できる非常に優れたプラットフォームです。
しかし、中規模から大規模のデータ テーブルであっても、Jmp がデータ テーブルの更新を完了するまで、ユーザーは長時間待たなければならない場合があります。
場合によっては、Update GUI で設定を編集しているときに Jmp が停止してしまうことがあります。
その後、Jmp がクラッシュしたように見えますが、数分後 (場合によっては数時間後)、Jmp はデータ プレビューの計算を終了し、ユーザーに再度設定を編集する機会を与えます。
あるテーブル内の何十万もの値を別のテーブル内の値と一致させるには、時間がかかることは明らかです。
しかし、2つの列を結合すると1つの列を結合するよりも2倍時間がかかることに驚きました
結合される列ごとにマッチング手順が再度トリガーされるのでしょうか、それとも実際には値の並べ替えに時間がかかるのでしょうか?
多くの場合、ソース テーブルには一意の識別子がありません。つまり、1 つの一致値が列に複数回表示され、マージする列にも同じ値が表示されます。この場合、最初の一致値がターゲット データ テーブルに入力され、次に 2 番目の一致値に置き換えられるなど、同様の処理が繰り返されるのではないかと思います。
ソース テーブルで最後に一致する値を検索し、その値を挿入するだけで、処理を高速化できます。
アップデート プラットフォームの大きな欠点:
列の追加と列の置換がアクティブになった状態で開始します。
たとえば、テーブルに 1000 列ある場合、すべての列がプレビュー ウィンドウに追加されるまでにしばらく時間がかかります。
この問題は、rows_main x rows_2nd x columns_2nd に応じて拡大縮小されます。
そして、私は愚かなので、一致する列を定義することから始めることがよくあります...これにより、実際にテーブルに追加したい (1 ～ 2) 列を選択できるようになるまで、長い道のりを歩むことになります。
テーブルが大きすぎる場合はプレビューを無効にする機能があります。
しかし、この関数はテーブルの長さだけをチェックし、列の数をチェックしないのではないかと心配しています。
それとも閾値が大きすぎるのでしょうか?
プレビュー タブの更新後、Jmp セッションが復旧するまでにどのくらいの頻度で時間を埋めなければならなかったか、あなたの経験を共有してください。
もう一つの問題はリコールボタンだ
(ここで対処: Recall による GUI の入力中にプレビューを無効にする)
「リコール」をクリックすると、「更新」メニューに保存された設定が表示されます。また、GUI 設定を変更するたびに、プレビュー タブが更新されるようです。
したがって、大きなデータ テーブルを結合する場合 (単一の列を追加するだけの場合であっても)、プレビューを無効にする前に [リコール...] を押さないでください。
どのような改善を望みますか?
Tables/Update のパフォーマンスを改善していただけますか。
このアイデアはなぜ重要なのでしょうか?
テーブル/更新は素晴らしい機能です。プレビュー タブは驚くほど便利なので、これなしでは作業できません。
しかし、私は不安になり始めています。次にデータ テーブルに列を追加しようとすると、どれくらいの時間がかかるのでしょうか。
データのブレンドとクリーンアップRe: テーブル/更新の高速化私たちの側からの優先度は低いです - https://community.jmp.com/t5/JMP-Wish-List/Speed-up-Tables-Update/idc-p/653334/highlight/true#M4531のアイデアに沿って回避策を実装しました
