Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenzaHo usato diversi modi per creare sottoinsiemi di una tabella lunga (righe> 100 K, dimensione molto comune di datatable). Il problema sorge perché il subset richiede la selezione di righe che significa un'operazione sulla tabella prima del subsetting. E se il tavolo è lungo lo rende molto lento. specialmente quando è necessario un ciclo foor per generare grafici sottoponendo ogni volta un nuovo parametro.
non importa quello che usi, è solo lento: non sono sicuro che il team JMP abbia qualche soluzione per velocizzare la subsetting ??????
seleziona le righe dove
ottenere righe dove
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenzaPerché stai sostituendo la tabella dei dati?
Prova a selezionare i dati che non vuoi, imposta lo stato di riga Nascondi ed escludi, crea il tuo grafico e ripeti per il gruppo successivo.
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenzaInoltre, potresti realizzare lo stesso compito usando i filtri?
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenzaPenso di aver detto chiaramente che il problema sorge quando selezioni i dati, il che rallenta.
ma potrei non essere in grado di capire cosa stai suggerendo. potresti fornire un esempio JSL. sicuramente proverò se accelera le cose.
Grazie
ariete
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenza@Dan_Obermiller
potresti aggiungere JSL per farlo in ciclo for senza il filtro pop-up?
Grazie
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenzaNon ho mai avuto un problema se uso ottenere righe dove o anche solo le righe. In realtà non devi selezionarli.
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));
Cosa stai usando per selezionare le righe? È possibile che sia lento.
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenzaEcco un semplice esempio di come eseguire le analisi per gruppi senza subsetting
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;
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenzaSembra che ci siano parecchie cose in corso nel tuo script: selezione, sottotitoli, creazione di report, tutto all'interno di un ciclo. Penso che sarebbe utile vedere uno script di esempio. Come viene fatta la selezione? I sottoinsiemi sono collegati alla tabella dei dati originale? Quali piattaforme vengono create? Quante iterazioni di questo ciclo vengono eseguite? Se le tabelle di sottoinsieme sono collegate e i report hanno il ricalcolo automatico abilitato, allora il processo potrebbe rallentare a ogni iterazione poiché tutti i report precedenti ricevono notifiche sulla selezione che si verifica nella tabella di origine. Se questo è il problema, l'approccio al filtro dei dati suggerito da altri potrebbe risolvere il problema perché ogni rapporto sarebbe isolato dalla successiva iterazione del ciclo.
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenza @vince_faller attualmente io uso lo stesso metodo. ma quando la dimensione del file diventa più grande, anche ottenere matrice di file diventa più grande e lento.
se usi una piccola tabella di dati come
<SPAN class="token string">Big Class.jmp</SPAN>
, tutto può funzionare. il problema è con i file di dati Big.
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenza@txnelson
Ci sono due problemi con il tuo approccio.
1. stai usando "select where (" che è la vera causa principale della tabella più grande. una volta che usi seleziona dove è l'operazione di aggiornamento della tabella dati di selezione delle righe (nel mio caso> 300K righe) stai semplicemente usando la classe Big che non è nemmeno contata per una dimensione del file.
2. questo non funziona per la situazione qui sotto
se dovessi correlare i dati di altezza su X_axis per sesso = "M" e dati di altezza su Y_axis per sex = "F".
spero che possa aiutarti a capire il problema ora
Grazie
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenza@danschikore
non è il numero di iterazioni. è la selezione di file che è lenta quando si hanno file di grandi dimensioni.
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenzaQuindi con questa tabella di un milione di righe. Ci vuole un sesto di secondo per correre. Probabilmente ha qualcosa a che fare con il tuo copione. Piace @danschikore Detto questo, se hai dato un esempio di script che rallenta potremmo essere in grado di aiutarti.
Names Default to Here( 1 );
dt = New Table("Test",
Add Rows(1000000),
New Column("X", Character, <<SET each="" value=""></SET>
Se chiami un sesto di secondo lento, allora non so cosa dirti.
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenzaQuindi con questa tabella di un milione di righe. Ci vuole un sesto di secondo per correre. Probabilmente ha qualcosa a che fare con il tuo copione. Come ha detto Dan, se hai dato un esempio di script in modo lento potremmo essere in grado di aiutarti.
Names Default to Here( 1 );
dt = New Table("Test",
Add Rows(1000000),
New Column("X", Character, <<SET each="" value=""></SET>
Se chiami un sesto di secondo lento, allora non so cosa dirti.
Inoltre, se stai utilizzando un ciclo for per generare una serie di grafici per ogni parametro, c'è un motivo per cui non stai usando un?
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenzaForse i tuoi criteri di selezione sono molto complessi e questo è ciò che sta rallentando le cose. Non possiamo aiutarti ulteriormente se non fornisci:
1. La tua sceneggiatura
2. Un campione dei tuoi dati (resi anonimi se necessario)
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenza@pmroz
@vince_faller
Stavo solo praticando qui invece che puro teorico.
Di seguito è riportato lo script con alcune colonne aggiunte. a seconda delle esecuzioni, il risultato può richiedere fino a 2 secondi. Ho anche aggiunto un'attesa (0), in modo che possa accogliere anche l'aggiornamento del tempo di visualizzazione.
Questa volta è solo il sottotitolo di due file. Successivamente è possibile aggiungere altro tempo impiegato dallo script per unire i due file secondo alcuni criteri. e poi facendo un grafico bivariato. Diventa davvero lento.
Un sacco di dati vale la velocità sufficiente. ma se aggiungo qualche altro lotto ......
Try(close(datatable("Test"),nosave));
dt = New Table("Test",
Add Rows(1000000),
New Column("X", Character, <<SET each="" value=""></SET>
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenzaPossiamo fare solo cose teoriche perché non ci hai detto cosa stai effettivamente facendo.
Quindi, quando si eseguiva ciò, ci sono voluti circa. -4 secondi per me per un solo tavolo (non due). Lo trovo assolutamente ragionevole. Se stai facendo un sacco di altre azioni insieme al sottoinsieme, allora non è giusto dire che il sottoinsieme è lento. Se stai eseguendo questi in un ciclo for allora è probabile che cosa stai facendo nel ciclo for che sta causando il problema. Se stai eseguendo uno script, direi di non mettere in attesa (0) a meno che tu non abbia bisogno che l'utente veda la tabella. In effetti dovresti renderli privati / invisibili in modo da non rendere mai e usare il tempo non necessario.
Cosa stai cercando di fare? Mi sento come se fosse un Problema XY .
Se ci fai sapere cosa stai facendo, potremmo aiutarti a velocizzarlo.
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenzaQuanto sono complesse le query "ottieni righe dove"? Quello che hai postato dovrebbe essere abbastanza veloce perché è solo alla ricerca di un valore, ma ho visto prestazioni più lente con query più complicate.
Ecco un semplice esempio che mostra una differenza di orario per il comando subset, rendendo i sottoinsiemi invisibili e quindi privati.
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));
Tempi sottoinsiemi invisibili:
"New rows: 1095"
"Old rows: 964"
"New subset: 3527"
"Old subset: 3366"
Intervalli di sottoinsiemi privati:
"New rows: 949"
"Old rows: 883"
"New subset: 1861"
"Old subset: 1638"
Come puoi vedere, il passaggio da invisibile a privato ha ridotto a metà il tempo del sottoinsieme.
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenzaDai suoni di esso, si susseguono sottomettere tabelle da una colonna e unendoli insieme. Potresti averlo semplicemente semplificato per esempio, ma se volessi tracciare Y (altezza, sesso == M), X (altezza, sesso == F). Vorrei solo dividere il tavolo. Questi due script, un sottoinsieme e join vs uno split, mostrano che la divisione dura circa un terzo del tempo.
names default to here(1);
dt = new table("Test",
add rows(1000000),
New column("sex", character, <<SET each="" value=""></SET>
Inoltre, con Linked non puoi modificare i nomi delle colonne e altre proprietà in modo da non poter cambiare il nome della colonna in modo che il join risulti un po 'più brutto.
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenzaEcco una panoramica più semplice di ciò che sto facendo. ricorda che questa è la forma più semplice di datatable e script che è ancora veloce rispetto al reale. Ho eseguito questo sul mio comp e ottenendo 2 secondi. alcune persone dicono che non è male. ma ricorda che stiamo parlando del tempo del computer non del tempo umano. 2sec è come il periodo di tempo della seconda guerra mondiale.
puoi provare questo per sapere quanto può essere cattivo: ridurre e aumentare il numero di righe di un fattore di 10 nella sezione "aggiungi righe (1000000).
Try(close(datatable("Test"),nosave));
dt = New Table("Test",
Add Rows(1000000),
New Column("X", Character, <<SET each="" value=""></SET>Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenzaIl problema più grande potrebbe essere il non aver menzionato l'aggiornamento / join.
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenza@Ciao @ram_asra_gmail_ ,
Non sono sicuro di quale problema si presenti in termini di velocità, ma lo sarà sicuramente in termini di risultati: la sintassi per il tuo aggiornamento non è corretta. Le specifiche corrette per le colonne delle corrispondenze che utilizzano l'aggiornamento sono colonne di corrispondenza () non corrispondenti a colonne (). Quest'ultimo incollerà la tabella degli aggiornamenti sulla tabella originale in termini di righe, che in realtà sarà molto più veloce di quella effettiva. Se usi Join, è "In base a colonne ()".
Ecco la sintassi corretta per l'aggiornamento:
datatable("sub1") << update(
With( Data Table( "Sub2" ) ),
Match Columns( :X1 = :X2, :P1 = :P2 )
);
Certamente non è l'unica cosa che sta succedendo, ma ho pensato che dovrei menzionarlo nel caso non fosse stato visto altrove!
@julian
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenzaSì, questo non ha quasi nulla a che fare con le tabelle di subsetting. Posso portare questo script a 100 righe e ci vogliono ancora 7 secondi.
Il mio primo suggerimento sarebbe di non eseguire ciascun bivariato in modo indipendente. Eseguili come piattaforme (o all'interno di vlistbox ()) in modo che non vengano valutate e aggiunte. Quindi mostra solo alla fine. Farlo mi ha portato a 3 secondi. Lo script è allegato.
Ma sembra DAVVERO che stai solo cercando di dividere una tabella di dati. La funzione split probabilmente sarebbe meglio di questo. Se devi farlo in questo modo per qualsiasi motivo. Concatiderei tutte le tue tabelle dt_sub1 con una per colonna ed eseguirle tutte in una volta. Ma scommetto che potrebbe essere ottimizzato una tonnellata.
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenzaCon la sintassi corretta a cui si fa riferimento @julian e un numero di righe ridotto di 10.000 ho avuto un tempo di esecuzione medio di 2.45 secondi (ho anche reso invisibili i bivariati).
Sostituire l'aggiornamento con un join invisibile ha ridotto il tempo di esecuzione medio a 0.67 secondi. L'aspetto critico di questo era la caduta di colonne non necessarie per la bivariata. Non lasciarli cadere li renderebbe molto più lenti.
Se il join è il collo a bottiglia, potresti voler pensare di eseguire un join virtuale. Per fare ciò, devi prima creare una singola colonna che sarebbe la chiave univoca per il join.
Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenzaPenso che questo trucco possa aiutare a ridurre un po 'di tempo. Approfitto già del sottoinsieme invisibile. ma può fare solo così tanto.
Grazie per aver fatto alcuni esperimenti.Ri: Il più grande problema in JMP nelle tabelle delle sotto-tabelle .... indolenza @Craige_Hales Sembra che il sottoinsieme collegato possa ridurre il tempo di molto. ma devo controllare con la sceneggiatura che ho postato due cose:
1. Ripetendo, ricevo il tempo medio migliorato
2. Sarò ancora in grado di unire le due tabelle sottoinsieme per rendere successivamente il grafico XY.
Grazie
