Scripting e file molto grandiHo uno script che importa molti file e li concatena.
Questo file può essere> 41 milioni di righe ed essere tra i 10 di Gigabit (ho 100 di GB di spazio libero e 128 GB di memoria: utilizzo di JMP16.2)
Ho quindi degli script per selezionare righe e colonne e così via.La mia domanda in realtà non riguarda lo scripting in sé, ma perché se eseguo ogni script in ordine anziché avere uno script che include tutti gli script, JMP "si blocca".
Per esempio, Tutto sembra funzionare in quanto se eseguo ogni JSL in ordine, funziona
1. Concat_files.JSL
2. Change_Test_Instance_Name.JSL
3. Riepiloga_istanza_di_test.JSL
vs
uno script che esegue ciascuno dei precedenti per me ...
Per esempio,
Esegui_tutti_script.JSL
include("ADDIN_HOME(my_scripts)\Concat_files.jsl");
include(("ADDIN_HOME(my_scripts)\Change_Test_Instance_Name.JSL");
include("ADDIN_HOME(my_scripts)\Summarize_Test_Instance.JSL.jsl");
Questo blocca solo il mio sistema ....Ho il registro aperto e posso dire che è bloccato nello script successivo (il registro mostra un'istruzione show come show("Entering Change_Test_Instance name");
Ho provato a usare wait(); istruzioni tra ciascuna inclusione (e all'interno di ciascuno degli script), ma ciò non funziona ancora.C'è qualcos'altro che dovrei provare?
Automazione e scriptingRi: Scripting e file molto grandiScusa per il ritardo nella risposta (impegnato con il lavoro).
Grazie per le idee.Non ho mai usato il debugger.
Esaminerò anche l'idea dello spazio dei nomi.Ho anche scoperto che se ho il DT principale aperto (è stato concatenato) e quindi eseguo lo script con l'istruzione include, viene eseguito anche alla stessa velocità di quando eseguo lo script così com'è (nessuna inclusione).Quindi qualcosa sulla tabella dei dati principale che è in memoria per un po 'rispetto alla concatenazione e quindi all'esecuzione immediata dello script di inclusione.
Ri: Scripting e file molto grandiPotresti essere in grado di eseguire il codice con il debugger/profiler JSL o semplicemente strumentarlo con time_start..time_end a grana più fine come stai facendo. La mia ipotesi è che il codice abbia un comportamento N ^ 2 (tempo 4 volte per raddoppiare i dati) per qualche motivo con gli include. Forse un problema di spazio dei nomi con un nome che collide con un nome nella tabella dei dati.
Un posto che potrebbe essere brutto è
dt_summary << select where( Contains( Test_names, :Test_Instance ) );
ma è difficile saperlo senza cronometrarlo. Se Test_names potrebbe avere 1e6 elementi e dt_summary potrebbe avere 1e6 righe, in media 500.000 test_names verrebbero esaminati su ciascuna delle 1e6 righe. O forse ce ne sono solo 10 o giù di lì e non è un problema. Potresti volerlo riscrivere, più o meno così
// untested. combine two loops and use an aa rather than a list for lookup
Test_names = AssociativeArray();
For Each Row(
If( ( Contains( dt_summary:Test_Instance, "CHAR_char" )),
Test_names[ dt_summary:Test_Instance ] = 1
)
);
dt_summary << select where( Test_names<<CONTAINS></CONTAINS>
L'array associativo sarà molto più veloce se l'elenco contiene diverse centinaia di elementi.
Se vuoi usare il profiler JSL, non fare la corsa di 3 ore per la tua prima esperienza di profiling. Prova un piccolo programma, usando un include, e assicurati di giocare con questi pulsanti:
Something in the toolboxSomething in the toolboxQualcosa nella cassetta degli attrezzi
A new window opens, the clock is for timing JSL.A new window opens, the clock is for timing JSL.Si apre una nuova finestra, l'orologio è per il cronometraggio JSL.
The tooltip for the icon says "run profiler".The tooltip for the icon says "run profiler".Il suggerimento per l'icona dice "esegui profiler".
potresti essere in grado di utilizzare il pulsante di pausa blu o attendere che finisca, quindi esaminare i punti caldi:
tabs for sourcestabs for sourcesschede per le fonti
tabs for sourcestabs for sources schede per le fonti
Ri: Scripting e file molto grandiSembra che io abbia incollato lo stesso log....
Ecco quando correre da solo...200 o circa 3,33 minuti
N Rows(dt) = 41929065;
"In Reduce_Test_Instance";
As Date(Today()) = 15Feb2022:10:11:57;
"Reducing Test Instances Ended";
As Date(Today()) = 15Feb2022:10:15:17;
start_time - As Date(Today()) = -200;
Ri: Scripting e file molto grandiHo lasciato eseguire lo script per vedere se era bloccato (sembra che fosse in esecuzione, ma ci vogliono ore, non minuti durante l'esecuzione all'interno di uno script).
Ho solo istruzioni show nel registro.
Ecco l'output del log per l'esecuzione di script all'interno di uno script.(Il "passaggio a un'istanza di test" richiede 3,65 ore contro 3,65 minuti se eseguo lo stesso script da solo sullo stesso file).La CPU utilizzava 12 core (da CPU0 a CPU11) circa il 20% per le 3,65 ore
Ecco i registri e uno snippet del JSL di seguito.
N Items(files_open) = 12;
"Files are Concatenated ";
As Date(Today()) = 14Feb2022:13:00:32;
start_time - As Date(Today()) = -492;
"Saving Digital_shmoo_all";
As Date(Today()) = 14Feb2022:13:00:54;
"Done Saving Digital_shmoo_all";
As Date(Today()) = 14Feb2022:13:01:24;
"Changing to one test instance";
N Rows(dt) = 41929065;
"In Reduce_Test_Instance";
As Date(Today()) = 14Feb2022:13:01:39;
"Reducing Test Instances Ended";
As Date(Today()) = 14Feb2022:16:41:13;
start_time - As Date(Today()) = -13174;
"Transposing";
"File has been transposed";
As Date(Today()) = 14Feb2022:16:42:23;
start_time - As Date(Today()) = -69;
Se eseguo lo script dell'istanza di test di riduzione da solo con lo stesso file di grandi dimensioni, ecco il log
As Date(Today()) = 14Feb2022:13:01:24;
"Changing to one test instance";
N Rows(dt) = 41929065;
"In Reduce_Test_Instance";
As Date(Today()) = 14Feb2022:13:01:39;
"Reducing Test Instances Ended";
As Date(Today()) = 14Feb2022:16:41:13;
start_time - As Date(Today()) = -13174;
"Transposing";
"File has been transposed";
As Date(Today()) = 14Feb2022:16:42:23;
start_time - As Date(Today()) = -69;
Le basi di questo script sono trovare nomi che iniziano con "Char_Char" e cambiarli in modo che non abbiano "Char_Char" ; In questo modo creando una tabella di riepilogo, selezionando le righe nella tabella di riepilogo che hanno "Char_Char", ottenendo le righe nella tabella principale che sono selezionate, quindi modificando il nome nella tabella principale.Ecco uno snipping della sceneggiatura lenta.
One_Test_Instance.JSL
dt = Current Data Table();
Names Default To Here( 1 );
Show( N Rows( dt ), "In Reduce_Test_Instance" );
Show( As Date( Today() ) );
start_time = As Date( Today() );
dt << clear select;
dt << clear column selection;
Wait();
Test_names = {};
dt << Summary(
Group( :Test_Instance ),
Freq( "None" ),
Weight( "None" ),
output table name( "Summary_of_Table" )
);
dt_summary = Current Data Table();
Wait();
For Each Row( Insert Into( Test_names, dt_summary:Test_Instance ) );
Wait();
For( i = N Items( Test_names ), i > 0, i--,
If( (!Contains( Test_names[i], "CHAR_char" )),
Remove From( Test_names, i )
)
);
dt_summary << select where( Contains( Test_names, :Test_Instance ) );
Wait();
aa = dt << get selected rows; //Get selected rows in main table
Wait();
Close( dt_summary, nosave );
If( N Rows( aa ) > 0,
(dt:Test_instance[aa]) = "CHAR_char_meas_TI";
(dt:Setup[aa]) = "meas_TI"; //Change name in main table
);
dt << clear select;
dt << clear column selection;
Wait();Ri: Scripting e file molto grandiStai aprendo/chiudendo finestre di report, forse 100 o 1000? Non aprire affatto le finestre potrebbe aiutare, molto. (Forse il sistema operativo non ha la possibilità di ripulire qualcosa.)
Stai stampando migliaia di righe nel registro JMP 16? C'è una preferenza per usare il vecchio formato di registro che potrebbe aiutare.
Task manager potrebbe fornire alcune informazioni. Guarda gli handle e gli oggetti GDI, nonché la memoria ovvia e i colpevoli del disco.
Oppure controlla la luce del disco sulla parte anteriore del computer, se ne hai uno. Non sembra che tu debba essere cercapersone, è un bel computer!
Mi piacerebbe sapere cosa stava succedendo quando ottieni una risposta; se nulla sopra aiuta, anche il supporto tecnico può aiutare.