211233_de-DE

liliconcom

Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

Ich habe mehrere Methoden verwendet, um eine lange Tabelle zu unterteilen (Zeilen> 100 KB, sehr häufige Größe der Datentabelle). Das Problem tritt auf, weil für die Teilmenge Zeilen ausgewählt werden müssen, was eine Operation für die Tabelle vor der Teilmenge bedeutet. Und wenn der Tisch lang ist, wird er sehr langsam. Dies gilt insbesondere dann, wenn eine Foor-Schleife erforderlich ist, um Diagramme zu erstellen, indem jedes Mal ein neuer Parameter untergeordnet wird.

Es spielt keine Rolle, was auch immer Sie verwenden, es ist nur langsam: Ich bin nicht sicher, ob das JMP-Team eine Lösung zur Beschleunigung der Teilmenge hat.

 

Zeilen auswählen, in denen

Holen Sie sich Zeilen, wo

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

Warum setzen Sie die Datentabelle unter?

 

Wählen Sie die Daten aus, die Sie nicht möchten, legen Sie den Zeilenstatus Ausblenden und Ausschließen fest, erstellen Sie ein Diagramm und wiederholen Sie dies für die nächste Gruppe.

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

Könnten Sie die gleiche Aufgabe auch mit Filtern ausführen?

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

Ich denke, ich habe es klar erwähnt, dass ein Problem auftritt, wenn Sie die Daten auswählen, was sie verlangsamt.

aber ich kann möglicherweise nicht verstehen, was Sie vorschlagen. könnten Sie JSL-Beispiel zur Verfügung stellen. Ich werde es mit Sicherheit versuchen, wenn es die Dinge beschleunigt.

Vielen Dank

RAM

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

@ Dan_Obermiller 

Könnten Sie JSL hinzufügen, um dies in der for-Schleife zu tun, ohne dass der Filter auftaucht?

Vielen Dank

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

Ich hatte noch nie ein Problem, wenn ich get-Zeilen verwende oder nur die Zeilen.  Sie müssen sie eigentlich nicht auswählen.  

 

names default to here(1);
dt = open("$SAMPLE_DATA\Big Class.jmp");
rows = dt << Get Rows Where(:sex == "M");
dt_sub = dt << Subset(rows(rows));

 Womit wählen Sie die Zeilen aus? Es ist möglich, dass das langsam ist. 

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

Hier ist ein einfaches Beispiel, wie Sie die Analysen nach Gruppen ohne Untergruppe durchführen können

Names Default To Here( 1 );
dt = Open( "$SAMPLE_DATA/big class.jmp" );

// Reset the data table row states
dt << clear row states;

// Find the different values for Sex
Summarize( byGroup = By( :sex ) );

// Loop across the different groups and analyze them
For( i = 1, i <= N Items( byGroup ), i++,

 // Reset the data table row states
 dt << clear row states;
 
 // Hide and Exclude the unwanted rows
 dt << select where( :Sex != byGroup[i] );
 dt << hide and exclude;
 
 // Run the analysis
 ow = dt << oneway( x( :age ), y( :height ) );
 
 // Change the title of the report to show what data are in the analysis
 Report( ow )[Outline Box( 1 )] << set title(
  Report( ow )[Outline Box( 1 )] << get title || ": Sex=" || byGroup[i]
 );
);

// Reset the data table row states
dt << clear row states;

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

Es hört sich so an, als ob in Ihrem Skript mehrere Dinge vor sich gehen - Auswahl, Teilmenge, Berichterstellung - alles in einer Schleife.  Ich denke, es wäre hilfreich, ein Beispielskript zu sehen.  Wie erfolgt die Auswahl? Sind die Teilmengen mit der ursprünglichen Datentabelle verknüpft? Welche Plattformen werden erstellt? Wie viele Iterationen dieser Schleife werden ausgeführt? Wenn die Teilmengen-Tabellen verknüpft sind und für die Berichte die automatische Neuberechnung aktiviert ist, verlangsamt sich der Prozess möglicherweise bei jeder Iteration, da alle vorherigen Berichte Benachrichtigungen über die Auswahl in der Quellentabelle erhalten.  Wenn dies das Problem ist, kann der von anderen vorgeschlagene Datenfilteransatz das Problem beheben, da jeder Bericht von der nächsten Iteration der Schleife isoliert wird.

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

@ vince_faller Derzeit verwende ich die gleiche Methode. Aber wenn die Dateigröße größer wird, wird sogar die Zeilenmatrix größer und langsamer. 

 

wenn Sie kleine Datentabelle wie verwenden

<SPAN class="token string">Big Class.jmp</SPAN>

kann alles funktionieren. Problem ist mit Big Data-Dateien.

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

@txnelson 

Es gibt zwei Probleme mit Ihrem Ansatz.

1. Sie verwenden "select where (", was die eigentliche Ursache für größere Tabellen ist. Sobald Sie select verwenden, um die Datentabelle zum Auswählen von Zeilen zu aktualisieren (in meinem Fall> 300 KB Zeilen), verwenden Sie nur die Klasse Big, die für eine Dateigröße nicht einmal gezählt wird.

 

2. Dies funktioniert nicht für die folgende Situation

Wenn ich Höhendaten für X_Achse für Geschlecht = "M" und Höhendaten für Y_Achse für Geschlecht = "F" in Beziehung setzen müsste.

Ich hoffe, es kann Ihnen helfen, das Problem jetzt zu verstehen

Vielen Dank

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

@danschikore 

es ist nicht die Anzahl der Iterationen. Dies ist die Auswahl von Zeilen, die bei großen Dateien langsam ist.

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

Also mit dieser Tabelle von einer Million Zeilen.  Der Lauf dauert eine Sechstelsekunde.  Es hat wahrscheinlich etwas mit Ihrem Skript zu tun.  Mögen @danschikore Wenn Sie ein Beispielskript dafür geben, das langsam läuft, können wir Ihnen möglicherweise helfen. 

 

Names Default to Here( 1 );
dt = New Table("Test", 
 Add Rows(1000000), 
 New Column("X", Character, <<SET each="" value=""></SET>

Wenn Sie eine Sechstelsekunde als träge bezeichnen, weiß ich nicht, was ich Ihnen sagen soll.  

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

Also mit dieser Tabelle von einer Million Zeilen.  Der Lauf dauert eine Sechstelsekunde.  Es hat wahrscheinlich etwas mit Ihrem Skript zu tun.  Wie Dan sagte, wenn Sie ein Beispielskript dafür geben, das langsam läuft, können wir Ihnen möglicherweise helfen. 

 

Names Default to Here( 1 );
dt = New Table("Test", 
 Add Rows(1000000), 
 New Column("X", Character, <<SET each="" value=""></SET>

Wenn Sie eine Sechstelsekunde als träge bezeichnen, weiß ich nicht, was ich Ihnen sagen soll.  

 

Wenn Sie eine for-Schleife verwenden, um eine Reihe von Plots für jeden Parameter zu generieren, gibt es einen Grund, warum Sie kein by verwenden?

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

Vielleicht sind Ihre Auswahlkriterien sehr komplex und das ist es, was die Dinge verlangsamt.  Wir können Ihnen nur weiterhelfen, wenn Sie Folgendes angeben:

1. Dein Drehbuch

2. Ein Beispiel Ihrer Daten (bei Bedarf anonymisiert)

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

@pmroz 

@ vince_faller  

Nur hier zu praktizieren, anstatt ein reiner Theoretiker zu sein.

Unten ist das Skript mit einigen hinzugefügten Spalten. Abhängig von den Läufen kann das Ergebnis bis zu 2 Sekunden dauern. Ich habe auch eine Wartezeit (0) hinzugefügt, damit die Anzeige auch aktualisiert werden kann.

Diese Zeit ist nur die Teilmenge von zwei Dateien. Danach können Sie zusätzliche Zeit hinzufügen, die das Skript benötigt, um die beiden Dateien nach bestimmten Kriterien zu verbinden. und dann ein bivariates Diagramm erstellen. Es wird wirklich langsam.

Eine Menge Daten ist genug Geschwindigkeit. aber wenn ich nur noch ein paar Lose hinzufüge ......

 

 

 

Try(close(datatable("Test"),nosave));
dt = New Table("Test", 
 Add Rows(1000000), 
 New Column("X", Character, <<SET each="" value=""></SET>

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

Wir können nur theoretische Dinge tun, weil Sie uns nicht gesagt haben, was Sie tatsächlich tun.  

 

Wenn ich das hier starte, dauerte es für mich ungefähr 0,3 bis 0,4 Sekunden für einen einzelnen Tisch (nicht für zwei von ihnen). Das finde ich völlig zumutbar.   Wenn Sie eine Reihe anderer Aktionen zusammen mit der Teilmenge ausführen, ist es nicht fair zu sagen, dass die Teilmenge langsam ist.  Wenn Sie diese in einer for-Schleife ausführen, ist es wahrscheinlich, was Sie in der for-Schleife tun, die das Problem verursacht.  Wenn Sie ein Skript ausführen, würde ich sagen, dass Sie nicht warten müssen (0), es sei denn, Sie möchten, dass der Benutzer die Tabelle sieht.  Tatsächlich sollten Sie sie privat / unsichtbar machen, damit sie niemals unnötige Zeit rendern und verbrauchen. 

 

Was versuchst du eigentlich zu tun? Ich fühle mich wie dies ist ein XY-Problem .  

 

Wenn Sie uns wissen lassen, was Sie tatsächlich tun, können wir Ihnen möglicherweise dabei helfen, das Verfahren zu beschleunigen.  

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

Wie komplex sind Ihre Abfragen zum Abrufen von Zeilen? Was Sie gepostet haben, sollte ziemlich schnell sein, da nur ein Wert gesucht wird, aber ich habe eine langsamere Leistung mit komplizierteren Abfragen festgestellt.

 

Hier ist ein einfaches Beispiel, das einen Zeitunterschied für den Teilmengenbefehl zeigt, indem die Teilmengen unsichtbar und dann privat gemacht werden.

dt = data table("Probe");
t1 = hp time();
new_rows = dt << get rows where(:Process == "New");
t2 = hp time();

old_rows = dt << get rows where(:Process == "Old");
t3 = hp time();

//s1 = dt << subset(rows(new_rows), invisible);
s1 = dt << subset(rows(new_rows), private);
t4 = hp time();

//s2 = dt << subset(rows(old_rows), invisible);
s2 = dt << subset(rows(old_rows), private);
t5 = hp time();

tn = t2 - t1;
to = t3 - t2;
ts1 = t4 - t3;
ts2 = t5 - t4;

print("New rows: " || char(tn));
print("Old rows: " || char(to));
print("New subset: " || char(ts1));
print("Old subset: " || char(ts2));

Unsichtbare Teilmengen-Timings:

"New rows: 1095"
"Old rows: 964"
"New subset: 3527"
"Old subset: 3366"

Private Subset-Timings:

"New rows: 949"
"Old rows: 883"
"New subset: 1861"
"Old subset: 1638"

Wie Sie sehen können, hat sich die Zeit der Teilmenge durch den Wechsel von unsichtbar zu privat halbiert.

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

Mein Computer ist sehr beschäftigt, daher variieren die Zahlen ein wenig, aber das Umstellen auf verknüpfte Untergruppen und das Entfernen des Wartens helfen. Das Entfernen der Wartezeit ist ungefähr dasselbe wie unsichtbar. Dadurch wird die Farbe des Tisches aus der Messung entfernt. Die Verwendung einer verknüpften Teilmenge ist ein großer Gewinn, da viele Daten nicht mehr verschoben werden müssen.

st=HPTIME();
rows = dt << Get Rows Where(:X == "C");
dt << Subset(rows(rows),outputtable("sub1"),"linked");
rows = dt << Get Rows Where(:X == "B");
dt << Subset(rows(rows),outputtable("sub2"),"linked");
//wait(0);
st=1e-6*(HPTIME()-st);
print(char(st)|| " Sec");

"2.534772 Sec" - nicht verbunden mit wait (0)

"1.50435 Sec" - nicht verbunden

"0.467098 Sec" - verknüpft

 

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

Aus den Klängen heraus setzen Sie Tabellen nach einer Spalte unter und fügen sie zusammen.  Sie haben es vielleicht nur zu stark vereinfacht, aber wenn ich Y (Größe, Geschlecht == M), X (Größe, Geschlecht == F) zeichnen wollte.  Ich würde einfach den Tisch teilen.  Diese beiden Skripte, eine Teilmenge und ein Join im Vergleich zu einem Split, zeigen, dass der Split etwa ein Drittel der Zeit in Anspruch nimmt.  

 

names default to here(1);
dt = new table("Test", 
 add rows(1000000), 
 New column("sex", character, <<SET each="" value=""></SET>

Außerdem können Sie mit "Verknüpft" die Spaltennamen und andere Eigenschaften nicht ändern, sodass Sie den Namen der Spalte nicht ändern können, sodass der Join etwas hässlicher aussieht.  

 

 

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

Hier ist eine einfachere Übersicht über das, was ich tue. Denken Sie daran, dies ist die einfachste Form von Datentabelle und Skript, die im Vergleich zur tatsächlichen immer noch schnell ist. Ich habe dies auf meinem Computer ausgeführt und erhalte durchschnittlich 2 Sekunden. Einige Leute sagen, das sei nicht schlecht. Aber denken Sie daran, wir sprechen von Computerzeit und nicht von menschlicher Zeit. 2sec ist wie im 2. Weltkrieg.

Sie können dies versuchen, um zu wissen, wie schlimm es sein kann: Reduzieren und Erhöhen Sie die Anzahl der Zeilen um den Faktor 10 unter "Zeilen hinzufügen" (1000000).

Try(close(datatable("Test"),nosave));
dt = New Table("Test", 
 Add Rows(1000000), 
 New Column("X", Character, <<SET each="" value=""></SET>

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

Das größte Problem könnte sein, dass Sie das Update / Join nicht erwähnt haben.

 

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

@Hallo @ram_asra_gmail_ ,

Ich bin mir nicht sicher, was für ein Problem dies in Bezug auf die Geschwindigkeit mit sich bringt, aber es wird sicherlich in Bezug auf die Ergebnisse: Die Syntax für Ihr Update scheint falsch zu sein. Die richtige Spezifikation für Übereinstimmungsspalten unter Verwendung von Aktualisieren lautet Übereinstimmungsspalten () und nicht Übereinstimmungsspalten (). Letzteres wird die Aktualisierungstabelle zeilenweise auf Ihre Originaltabelle kleben, was in der Tat sehr wahrscheinlich schneller ist als das eigentliche Match. Wenn Sie "Verbinden" verwenden, wird "Nach übereinstimmenden Spalten ()" angezeigt.

 

Hier ist die korrekte Syntax für Update:

 

datatable("sub1") << update(
 With( Data Table( "Sub2" ) ),
 Match Columns( :X1 = :X2, :P1 = :P2 )
);

 

Sicher nicht das Einzige, aber ich dachte, ich sollte es erwähnen, falls es woanders nicht entdeckt wurde!

@julianisch 

 

 

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

Ja, das hat fast nichts mit Subsetting-Tabellen zu tun.  Ich kann dieses Skript auf 100 Zeilen reduzieren und es dauert immer noch 7 Sekunden.  

 

Mein erster Vorschlag wäre, nicht jedes Bivariate einzeln zu betreiben.  Führen Sie sie als Plattformen (oder in vlistbox ()) aus, damit sie nicht ausgewertet und angehängt werden.  Dann zeig es einfach am Ende.  Das hat mich auf 3 Sekunden gebracht.  Skript ist beigefügt.  

 

Aber es sieht WIRKLICH so aus, als würden Sie nur versuchen, eine Datentabelle zu teilen.  Die Split-Funktion wäre wahrscheinlich besser als dies zu tun.  Wenn du es aus irgendeinem Grund so machen musst. Ich würde alle Ihre dt_sub1-Tabellen zusammen mit einer by-Spalte zusammenfassen und sie alle auf einmal ausführen.  Aber ich wette, das könnte eine Tonne optimiert werden.  

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

Mit der korrigierten Syntax von @julianisch und eine reduzierte Zeilenanzahl von 10.000 hatte ich eine durchschnittliche Ausführungszeit von 2,45 Sekunden (ich habe auch die Bivariaten unsichtbar gemacht).

 

Das Ersetzen des Updates durch einen unsichtbaren Join reduzierte die durchschnittliche Ausführungszeit auf 0,67 Sekunden.  Ausschlaggebend dafür war das Ablegen von Säulen, die für das Bivariate nicht benötigt wurden.  Wenn Sie sie nicht fallen lassen, wird sie erheblich langsamer.

 

Wenn es sich bei der Verknüpfung um den Flaschenhals handelt, sollten Sie über eine virtuelle Verknüpfung nachdenken.  Dazu müssten Sie zunächst eine einzelne Spalte erstellen, die der eindeutige Schlüssel für den Join ist.

 

Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... TrägheitIch denke, dieser Trick kann helfen, die Zeit zu verkürzen. Ich nutze bereits eine unsichtbare Teilmenge. aber es kann nur so viel.
Vielen Dank für einige Experimente.Betreff: Größtes Problem bei JMP in untergeordneten Einstellungstabellen .... Trägheit

@Craige_Hales Verknüpfte Untermengen können die Zeit um ein Vielfaches verkürzen. Aber ich muss mit dem Skript überprüfen, ich habe zwei Dinge gepostet:

1. Durch Wiederholen erhalte ich die verbesserte durchschnittliche Zeit

2. Kann ich die beiden Subset-Tabellen weiterhin verbinden, um anschließend ein XY-Diagramm zu erstellen?

Vielen Dank