211233_fr-FR

liliconcom

Plus gros problème de JMP dans les sous-tables .... lenteur

J'ai utilisé plusieurs méthodes pour sous-définir une longue table (lignes> 100 Ko, taille très commune de datatable). Le problème se pose car la sous-définition nécessite la sélection de lignes, ce qui signifie une opération sur la table avant la sous-définition. Et si la table est longue, cela la rend très lente. spécialement quand une boucle de sol est nécessaire pour générer des tracés en sous-paramétrant à chaque fois un nouveau paramètre.

peu importe ce que vous utilisez, il est simplement lent: je ne suis pas sûr que l’équipe JMP ait une solution pour accélérer le sous-paramétrage ??????

 

sélectionner les lignes où

obtenir des rangées où

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

Pourquoi sous-configurez-vous la table de données?

 

Essayez de sélectionner les données que vous ne voulez pas, définissez l'état des lignes Masquer et Exclure, créez votre tracé et répétez l'opération pour le groupe suivant.

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

Aussi, pourriez-vous accomplir la même tâche en utilisant des filtres?

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

Je pense avoir mentionné clairement que le problème se pose lorsque vous sélectionnez les données, ce qui les ralentit.

mais je ne serai peut-être pas capable de comprendre ce que vous suggérez. pourriez-vous donner un exemple JSL. je vais sûrement essayer si cela accélère les choses.

Merci

RAM

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

@Dan_Obermiller 

Pourriez-vous ajouter JSL pour faire cela dans la boucle sans que le filtre n'apparaisse?

Merci

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

Je n'ai jamais eu de problème si j'utilise obtenir des lignes où ou même juste les lignes.  Vous n'êtes pas obligé de les sélectionner.  

 

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'utilisez-vous pour sélectionner les lignes? C'est possible c'est lent. 

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

Voici un exemple simple de la façon de faire les analyses par groupes sans sous-définition

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: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

Il semble que plusieurs choses se passent dans votre script: sélection, sous-paramétrage, création de rapports, le tout dans une boucle.  Je pense qu'il serait utile de voir un exemple de script.  Comment se fait la sélection? Les sous-ensembles sont-ils liés à la table de données d'origine? Quelles sont les plateformes en cours de création? Combien d'itérations de cette boucle sont exécutées? Si les tables de sous-ensembles sont liées et que la recalcul automatique est activée sur les rapports, le processus ralentit peut-être à chaque itération, car tous les rapports précédents reçoivent des notifications concernant la sélection dans la table source.  Si tel est le problème, l'approche de filtrage des données suggérée par d'autres peut résoudre le problème, car chaque rapport serait isolé de la prochaine itération de la boucle.

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

@vince_faller Actuellement, j'utilise la même méthode. mais lorsque la taille du fichier devient plus grande, même obtenir la matrice de lignes devient plus grand et plus lent. 

 

si vous utilisez une petite table de données comme

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

, tout peut fonctionner. problème est avec Big fichiers de données.

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

@txnelson 

Il y a deux problèmes avec votre approche.

1. vous utilisez "select where ("), qui est la véritable cause première du grand tableau une fois que vous utilisez select où il s’agit de mettre à jour le tableau de données de sélection des lignes (dans mon cas, plus de 300 000 lignes), vous utilisez simplement Big class qui n’est même pas comptabilisée pour la taille du fichier.

 

2 cela ne fonctionne pas pour la situation ci-dessous

si je devais corréler les données de hauteur sur X_axis pour le sexe = "M" et les données de hauteur sur Y_axis pour le sexe = "F".

J'espère que cela peut vous aider à comprendre le problème maintenant

Merci

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

@danschikore 

ce n'est pas le nombre d'itérations. c'est la sélection des lignes qui est lente lorsque vous avez une grande taille de fichier.

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

Donc, avec cette table d'un million de lignes.  Il faut un sixième de seconde pour courir.  C'est probablement quelque chose à voir avec votre script.  Comme @danschikore dit, si vous avez donné un exemple de script qui tourne lentement, nous pourrons peut-être vous aider. 

 

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

Si vous appelez un sixième de seconde, alors je ne sais pas quoi vous dire.  

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

Donc, avec cette table d'un million de lignes.  Il faut un sixième de seconde pour courir.  C'est probablement quelque chose à voir avec votre script.  Comme Dan l'a dit, si vous donnez un exemple de script indiquant qu'il tourne lentement, nous pourrons peut-être vous aider. 

 

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

Si vous appelez un sixième de seconde, alors je ne sais pas quoi vous dire.  

 

De même, si vous utilisez une boucle for pour générer une série de graphiques pour chaque paramètre, y a-t-il une raison pour laquelle vous n'utilisez pas un by?

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

Peut-être que vos critères de sélection sont très complexes et que c'est ce qui ralentit les choses.  Nous ne pouvons pas vous aider davantage si vous ne fournissez pas:

1. Votre script

2 Un échantillon de vos données (anonymisé si nécessaire)

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

@pmroz 

@vince_faller  

Juste être praticle ici au lieu de théoricien pur.

Ci-dessous, le script avec quelques colonnes ajoutées. En fonction des courses, le résultat peut prendre jusqu'à 2 secondes. J'ai également ajouté un wait (0), afin qu'il puisse également accueillir la mise à jour du temps d'affichage.

Cette fois, il s’agit de la sous-définition de deux fichiers. Après cela, vous pouvez ajouter du temps supplémentaire par script pour joindre les deux fichiers en fonction de certains critères. et ensuite faire un graphique bivarié. Cela devient vraiment lent.

Une BEAUCOUP de données est suffisante. mais si je viens d'ajouter quelques lots de plus ......

 

 

 

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

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

Nous pouvons seulement faire des choses théoriques parce que vous ne nous avez pas dit ce que vous faites réellement.  

 

Ainsi, lors de l’exécution de cette tâche, il m’a pris environ 0,3 à 4 secondes pour une seule table (et non deux). Je trouve cela complètement raisonnable.   Si vous faites beaucoup d'autres actions avec le sous-ensemble, il est injuste de dire que le sous-ensemble est lent.  Si vous les utilisez dans une boucle for, le problème est probablement ce que vous faites dans la boucle for.  Si vous exécutez un script, je vous conseille de ne pas mettre le paramètre wait (0) à moins que vous n'ayez besoin que l'utilisateur voie la table.  En fait, vous devriez les rendre privés / invisibles afin qu’ils ne rendent jamais et n’utilisent pas du temps inutile. 

 

Qu'essayez-vous de faire? J'ai l'impression que c'est un Problème XY .  

 

Si vous nous faites savoir ce que vous faites réellement, nous pourrons peut-être vous aider à l'accélérer.  

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

Quelle est la complexité de vos requêtes "obtenir des lignes où"? Ce que vous avez publié devrait être assez rapide car il ne cherche qu'une valeur, mais j'ai constaté des performances plus lentes avec des requêtes plus complexes.

 

Voici un exemple simple montrant une différence de temps pour la commande de sous-ensemble, en rendant les sous-ensembles invisibles, puis privés.

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

Timings invisibles de sous-ensembles:

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

Timings privés de sous-ensemble:

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

Comme vous pouvez le constater, le passage de invisible à privé réduit de moitié le temps du sous-ensemble.

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

À partir de là, vous subdivisez les tableaux en colonnes et vous les assemblez.  Vous avez peut-être simplifié à l'extrême le saké, par exemple, mais si je voulais tracer Y (hauteur, sexe == M), X (hauteur, sexe == F).  Je voudrais juste diviser la table.  Ces deux scripts, un sous-ensemble et une jointure vs une scission, montrent que la scission prend environ un tiers du temps.  

 

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

En outre, avec Linked, vous ne pouvez pas modifier le nom des colonnes et d'autres propriétés. Vous ne pouvez donc pas modifier le nom de la colonne, de sorte que la jointure semble un peu plus laide.  

 

 

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

Voici un aperçu plus simple de ce que je fais. Rappelez-vous que c'est la forme la plus simple de datatable et de script qui est toujours rapide comparée à la réalité. Je l'ai couru sur mon ordinateur et obtenir avg 2sec. Certaines personnes disent que ce n'est pas mauvais. mais rappelez-vous que nous parlons de temps d'ordinateur et non de temps humain. 2sec est comme la période WW2.

Vous pouvez essayer ceci pour savoir à quel point cela peut être grave: réduisez et augmentez le nombre de lignes d'un facteur 10 dans l'option "ajouter des lignes (1000000)".

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

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

Le plus gros problème pourrait être que vous n'avez pas mentionné la mise à jour / rejoindre.

 

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

@Salut @ram_asra_gmail_ ,

Je ne sais pas à quel point cela pose un problème en termes de rapidité, mais il en va certainement de même pour les résultats: la syntaxe de votre mise à jour semble incorrecte. La spécification appropriée pour les colonnes de correspondance à l'aide de la mise à jour est Correspondance entre colonnes () et Colonnes correspondantes (). Ce dernier va coller la table de mise à jour sur votre table d'origine ligne par ligne, ce qui en fait sera très probablement plus rapide que la correspondance réelle. Si vous utilisez Joindre, c’est «En comparant les colonnes ()».

 

Voici la syntaxe correcte pour Update:

 

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

 

Certainement pas la seule chose qui se passe, mais je pensais que je devrais mentionner au cas où il n'a pas été repéré ailleurs!

@julien 

 

 

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

Oui, cela n'a presque rien à voir avec les tables de sous-ensembles.  Je peux ramener ce script à 100 lignes et cela prend encore 7 secondes.  

 

Ma première suggestion serait de ne pas exécuter chaque variable à deux variables indépendamment.  Exécutez-les en tant que plates-formes (ou dans vlistbox ()) afin qu'elles ne soient ni évaluées ni ajoutées.  Ensuite, montrez juste à la fin.  Cela m'a amené à 3 secondes.  Le script est attaché.  

 

Mais on dirait VRAIMENT que vous essayez simplement de scinder une table de données.  La fonction split serait probablement préférable à cette opération.  Si vous devez le faire comme ça pour une raison quelconque. Je concatemine toutes vos tables dt_sub1 avec une colonne by et les exécute toutes en même temps.  Mais je parie que cela pourrait être optimisé une tonne.  

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

Avec la syntaxe corrigée mentionnée par @julien et un nombre de lignes réduit de 10 000, j'ai eu un temps d'exécution moyen de 2,45 secondes (j’ai également rendu les variables bivariées invisibles).

 

Le remplacement de la mise à jour par une jointure invisible a réduit le temps moyen d’exécution à 0,67 secondes.  La suppression de colonnes inutiles pour le modèle bivarié était essentielle.  Ne pas les laisser tomber le rendrait beaucoup plus lent.

 

Si la jointure est le goulot d'étranglement, vous pouvez envisager de réaliser une jointure virtuelle.  Pour ce faire, vous devez d’abord créer une seule colonne qui serait la clé unique de la jointure.

 

Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteurJe pense que cette astuce peut aider à réduire un peu de temps. Je profite déjà du sous-ensemble invisible. mais il peut faire beaucoup seulement.
Merci d'avoir fait des expériences.Re: Le plus gros problème de JMP dans les sous-tables de configuration .... lenteur

@Craige_Hales Le sous-ensemble lié semble réduire considérablement le temps. mais je dois vérifier avec le script que j'ai posté deux choses:

1. En répétant puis-je obtenir le temps moyen amélioré

2 pourrai-je toujours joindre les deux tables de sous-ensembles pour créer ultérieurement un graphique XY?

Merci