211233_es-ES

liliconcom

El mayor problema en JMP en las tablas de sub configuración ... lentitud

He utilizado varias formas de subcontratar una tabla larga (filas> 100 K, tamaño muy común de datos). El problema surge porque el subconjunto requiere la selección de filas, lo que significa una operación en la tabla antes del subconjunto. Y si la mesa es larga lo hace muy lento. especialmente cuando se requiere un bucle de foor para generar gráficos mediante el subconjunto cada vez que un nuevo parámetro.

no importa lo que use, es lento: no estoy seguro si el equipo de JMP tiene alguna solución para acelerar el subconjunto ??????

 

selecciona filas donde

obtener filas donde

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

¿Por qué estás subcontratando la tabla de datos?

 

Intente seleccionar los datos que no desea, establezca el estado de fila Ocultar y Excluir, haga su trazado y repita para el siguiente grupo.

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

Además, ¿podrías lograr la misma tarea usando filtros?

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

Creo que lo mencioné claramente que el problema surge cuando seleccionas los datos, lo que los ralentiza.

pero es posible que no pueda entender lo que está sugiriendo. ¿Podría dar ejemplo JSL. Seguramente lo intentaré si acelera las cosas.

Gracias

RAM

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

@Dan_Obermiller 

¿Podría agregar JSL para hacer eso en el bucle for sin el filtro emergente?

Gracias

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

Nunca he tenido un problema si uso obtener filas donde o solo las filas.  En realidad no tienes que seleccionarlos.  

 

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));

 ¿Qué estás usando para seleccionar las filas? Es posible que sea lento. 

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

Aquí hay un ejemplo simple de cómo hacer los análisis por grupos sin subcontratar

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;

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

Parece que hay varias cosas en su script: selección, subconjunto, creación de informes, todo dentro de un bucle.  Creo que sería útil ver un script de ejemplo.  ¿Cómo se hace la selección? ¿Están los subconjuntos vinculados a la tabla de datos original? ¿Qué plataformas se están creando? ¿Cuántas iteraciones de este bucle se ejecutan? Si las tablas de subconjuntos están vinculadas y los informes tienen la recalificación automática habilitada, entonces es posible que el proceso se esté ralentizando con cada iteración, ya que todos los informes anteriores reciben notificaciones sobre la selección que se produce en la tabla fuente.  Si este es el problema, entonces el enfoque de filtro de datos que otros han sugerido puede solucionar el problema porque cada informe se aislaría de la próxima iteración del bucle.

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

@vince_faller Actualmente utilizo el mismo método. pero cuando el tamaño del archivo se hace más grande, incluso la matriz de filas se hace más grande y lenta. 

 

Si utiliza una pequeña tabla de datos como

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

, cualquier cosa puede funcionar. El problema es con los archivos de datos grandes.

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

@txnelson 

Hay dos problemas con su enfoque.

1. está utilizando "select where (", que es la causa raíz real de una tabla más grande. una vez que usa select donde está la operación de actualizar la tabla de datos de seleccionar filas (en mi caso> 300K filas), solo está usando la clase Big, que ni siquiera cuenta para un tamaño de archivo.

 

2. Esto no funciona para la situación de abajo.

si tuviera que correlacionar los datos de altura en X_axis para sex = "M" y los datos de altura en Y_axis para sex = "F".

Espero que te pueda ayudar a entender el problema ahora.

Gracias

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

@danschikore 

No es el número de iteraciones. es la selección de filas que es lenta cuando tiene un tamaño de archivo grande.

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

Así que con esta tabla de un millón de filas.  Se tarda un sexto de segundo en correr.  Probablemente sea algo que ver con tu guión.  Me gusta @danschikore dicho, si dio un ejemplo de script de ejecución lenta podremos ayudarlo. 

 

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

Si está llamando lento a un sexto de segundo, entonces no sé qué decirle.  

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

Así que con esta tabla de un millón de filas.  Se tarda un sexto de segundo en correr.  Probablemente sea algo que ver con tu guión.  Como dijo Dan, si dio un ejemplo de un script de ejecución lenta, podremos ayudarlo. 

 

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

Si está llamando lento a un sexto de segundo, entonces no sé qué decirle.  

 

Además, si está utilizando un bucle for para generar un montón de gráficos para cada parámetro, ¿hay alguna razón por la que no esté utilizando un by?

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

Tal vez sus criterios de selección son muy complejos y eso es lo que está ralentizando las cosas.  No podemos ayudarlo más a menos que proporcione:

1. Tu guion

2. Una muestra de sus datos (anonimizados si es necesario)

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

@pmroz 

@vince_faller  

Simplemente siendo práctico aquí en lugar de puro teórico.

A continuación se muestra el script con algunas columnas añadidas. Dependiendo de las ejecuciones, el resultado puede tardar hasta 2 seg. También agregué una espera (0), para que pueda acomodar la actualización del tiempo de visualización también.

Esta vez es solo el subconjunto de dos archivos. Después de eso, puede agregar el tiempo adicional que toma el script para unir los dos archivos según algunos criterios. y luego hacer un gráfico bivariado. Realmente se vuelve lento.

Un MUCHO valor de datos es suficiente velocidad. Pero si acabo de agregar algunos lotes más ......

 

 

 

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

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

Solo podemos hacer cosas teóricas porque no nos has dicho lo que realmente estás haciendo.  

 

Así que cuando ejecuté esto, me tomó cerca de .3-.4 segundos para una sola tabla (no dos de ellas). Me parece completamente razonable.   Si está realizando un montón de otras acciones junto con el subconjunto, entonces no es justo decir que el subconjunto es lento.  Si está ejecutando estos en un bucle for, entonces es probable que lo que está haciendo en el bucle for sea el causante del problema.  Si está ejecutando un script, diría que no ponga en espera (0) a menos que necesite que el usuario vea la tabla.  De hecho, debes hacerlos privados / invisibles para que nunca se procesen y usen tiempo innecesario. 

 

¿Qué estás realmente tratando de hacer? Siento que esto es un Problema XY .  

 

Si nos informa lo que realmente está haciendo, podríamos ayudarle a acelerarlo.  

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

¿Qué tan complejas son sus consultas "obtener filas donde"? Lo que publicaste debería ser bastante rápido porque solo busca un valor, pero he visto un rendimiento más lento con consultas más complicadas.

 

Este es un ejemplo simple que muestra una diferencia de tiempo para el comando de subconjunto, haciendo que los subconjuntos sean invisibles y luego privados.

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));

Tiempos de subconjuntos invisibles:

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

Tiempos de subconjuntos privados:

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

Como puede ver, el cambio de lo invisible a lo privado redujo el tiempo del subconjunto a la mitad.

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

Mi computadora está realmente ocupada, por lo que los números varían un poco, pero cambiar a subconjuntos vinculados y eliminar la espera ayuda, un montón. Eliminar la espera es más o menos lo mismo que invisible; saca de la medida la pintura de la mesa. El uso de un subconjunto vinculado es una gran ganancia, ya que no es necesario mover muchos datos.

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" - desvinculado con espera (0)

"1.50435 seg" - desvinculado

"0.467098 Sec" - vinculado

 

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

A partir de los sonidos del mismo, usted está subdividiendo tablas por una columna y uniéndolas.  Puede que lo hayas simplificado demasiado, por ejemplo, pero si quisiera trazar Y (altura, sexo == M), X (altura, sexo == F).  Yo solo dividiría la mesa.  Estos dos scripts, un subconjunto y unir vs una división, muestran que la división toma aproximadamente un tercio del tiempo.  

 

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

Además, con Linked no puede cambiar los nombres de columna y otras propiedades, por lo que no pudo cambiar el nombre de la columna para que la unión parezca un poco más fea.  

 

 

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

Aquí hay una descripción más simple de lo que estoy haciendo. recuerde que esta es la forma más simple de datos y secuencias de comandos que aún es rápida en comparación con la real. Corrí esto en mi comp y obteniendo avg 2sec. Algunas personas dicen que esto no es malo. pero recuerda que estamos hablando de tiempo de computadora no de tiempo humano. 2sec es como el período de tiempo WW2.

puede intentar esto para saber qué tan malo puede ser: reducir y aumentar el número de filas en un factor de 10 en "agregar filas (1000000).

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

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

El mayor problema puede ser que no hayas mencionado la actualización / unirse.

 

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

@Hola @ram_asra_gmail_ ,

No estoy seguro de la cantidad de problemas que esto presenta en términos de velocidad, pero ciertamente lo será en términos de resultados: la sintaxis de la actualización parece incorrecta. La especificación adecuada para las columnas de coincidencia que utilizan Actualizar es Coincidir con las columnas () no con las Columnas coincidentes (). Este último pegará la tabla de actualización en su tabla original por filas, lo que de hecho será más rápido que hacer la coincidencia real. Si usas Join, es "Coincidencia de columnas ()".

 

Aquí está la sintaxis correcta para la actualización:

 

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

 

Ciertamente no es lo único que está sucediendo, ¡pero pensé que debería mencionar en caso de que no se viera en ningún otro lugar!

@Julian 

 

 

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

Sí, esto casi no tiene nada que ver con las tablas de subconjunto.  Puedo bajar este script a 100 filas y aún toma 7 segundos.  

 

Mi primera sugerencia sería no ejecutar cada bivariado de forma independiente.  Ejecútelos como plataformas (o dentro de vlistbox ()) para que no los evalúen y añadan.  Entonces simplemente mostrar al final.  Haciendo justo eso me trajo a 3 segundos.  Se adjunta guión.  

 

Pero REALMENTE parece que solo estás intentando dividir una tabla de datos.  La función de división probablemente sería mejor que hacer esto.  Si tienes que hacerlo así por cualquier motivo. Reuniré todas tus tablas dt_sub1 junto con una por columna y las ejecutaré todas a la vez.  Pero apuesto a que esto podría optimizarse una tonelada.  

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

Con la sintaxis corregida referida por @Julian y un número reducido de filas de 10,000 tuve un tiempo de ejecución promedio de 2,45 Segundos (también hice invisibles los bivariados).

 

Reemplazar la actualización con una combinación invisible redujo el tiempo promedio de ejecución a 0.67 segundos.  Para esto fue crítico eliminar columnas que no son necesarias para la bivariada.  No dejarlos caer lo haría significativamente más lento.

 

Si la unión es el cuello de botella, es posible que desee pensar en realizar una unión virtual.  Para hacerlo, primero tendría que crear una sola columna que sería la clave única para la unión.

 

Re: El mayor problema en JMP en las tablas de sub configuración ... lentitudCreo que este truco puede ayudar a reducir el tiempo. Ya me aprovecho del subconjunto invisible. Pero puede hacer mucho solo.
Gracias por hacer algunos experimentos.Re: El mayor problema en JMP en las tablas de sub configuración ... lentitud

@Craige_Hales Parece que el subconjunto vinculado puede reducir mucho el tiempo. Pero tengo que verificar con el script que publiqué dos cosas:

1. Repitiendo obtengo el tiempo promedio mejorado

2. ¿Aún podré unir las dos tablas de subconjuntos para hacer un gráfico XY posteriormente?

Gracias