enregistrer html() lent ?<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />Lorsque j'utilise save html() sur une fenêtre de rapport, la sauvegarde prend TRÈS longtemps - peut durer une demi-heure ou plus pour une seule page.Ça marche au final.Est-ce que d'autres ont ce problème ?
Y a-t-il quelque chose que je puisse faire pour le rendre plus rapide ?ce ne sont pas des fichiers volumineux - 2 à 5 Ko seulement.A quoi pense-t-il ?Je veux faire cela dans le cadre d'un travail automatique, donc un seul rapport prenant une demi-heure est en fait OK, mais l'un des cas est celui où je veux parcourir de nombreux cas différents en créant cette sortie afin que cela puisse vraiment prendre trop de temps et le le travail peut être interrompu.
J'utilise saveinteractivehtml() dans d'autres cas et je n'ai pas ce problème même si les fichiers sont plus volumineux.Si j'utilise saveinteractivehtml sur cette même fenêtre, c'est également rapide mais c'est une fenêtre que saveinteractivehtml ne rend pas correctement.J'ai certaines sorties avec lesquelles je ne peux pas les utiliser.
J'ai ce problème avec au moins 2 fenêtres assez différentes - l'une est composée de tracés JMP, l'autre est principalement constituée d'images avec quelques annotations créées dans JMP.
apprécier toutes les suggestions sur ce qu'il faut essayer.
Re : enregistrer html() lentement ?Juste au cas où cela aiderait quelqu'un d'autre, j'ai également trouvé une solution pour mon cas d'archivage :
Le rapport en question fonctionne bien pour n'être qu'une vue d'ensemble même si JMP enregistrait plus de 40 éléments distincts pour chaque page afin que je puisse remplacer nw<
Probablement pour certains rapports, savehtml() fait beaucoup de travail et crée du HTML complexe, mais pour ce rapport non interactif, il est vraiment assez facile de bricoler le HTML en utilisant une seule image et en contrôlant moi-même tous les noms et emplacements de fichiers.
Re : enregistrer html() lentement ?Merci!Je vois que je peux certainement améliorer ce que j’ai au moins.
Re : enregistrer html() lentement ?Oui.À mesure que le nombre d’images augmente, il faut beaucoup plus de temps pour en ajouter une autre.Le chargement du HTML n'est pas un problème, mais l'écriture l'est.JMP 13 utilisera une partie de la date dans le nom du fichier pour éviter le ralentissement.
Quelque chose comme ça fonctionnera mieux et gardera le gfx+html organisé en même temps. Les dernières lignes suggèrent un moyen de conserver le fichier actuel dans un emplacement cohérent pour vos utilisateurs :
// exemple de script pour créer un dossier de rapport quotidien
dt = Ouvrir ( "$sample_data/big class.jmp" ) ;
rpt = dt << Bivarié ( Oui ( : poids ) , X ( : hauteur ) , Ligne d'ajustement ( { Couleur de la ligne ( { 213 , 72 , 87 } )} ) ) ;
// les noms de répertoires peuvent être composés uniquement de chiffres, mais vous souhaiterez peut-être une lettre,
// R pour rapport, peut-être, comme première lettre.Ou un meilleur titre.
// assurez-vous que le format de date ne contient pas de caractères / ou \ !
// le format AAAAMMJJ est sympa car il trie correctement
tous les jours = "R" || Format ( Aujourd'hui () , "aaaammjj" ) ;
chemin d'accès = "$bureau/" || tous les jours ;
Si ( ! Le répertoire existe ( chemin d'accès ) ,
Créer le répertoire ( chemin d'accès )
) ;
rpt << enregistrerhtml ( chemin d'accès || "/biv.html" ) ;
rpt << Fermer la fenêtre ;
Fermer ( dt , "nosave" ) ;
Créer le répertoire ( "$bureau/EmplacementFinal" ) ; // probablement déjà là depuis hier
Copier le répertoire ( chemin d'accès , "$bureau/EmplacementFinal" ) ; // utilisation quotidienne
Supprimer le répertoire ( "$bureau/EmplacementFinal/actuel" ) ; // nettoie le rapport d'hier
// fait du quotidien "R20160527" un nom fixe, "actuel"
Renommer le répertoire ( "$bureau/EmplacementFinal/" || tous les jours , "actuel" ) ;
Re : enregistrer html() lentement ?Donc, juste pour vérifier, si mon plan était de créer une archive croissante avec une nouvelle page pour chaque widget via notre usine, par exemple, cela est voué à devenir de plus en plus lent. Mais là où j'ai des pages qui s'écrasent chaque jour, je pourrais effacer périodiquement les images des jours précédents car elles ne sont plus utilisées et ce fichier pourrait rester petit. Je pourrais le supprimer automatiquement tôt le matin avant la mise à jour de tous les rapports et lorsque personne ne se plaindra que la page est cassée.....
J'en ai quelques-uns de chaque type, ce qui est peut-être le pire des cas, car je ne peux pas facilement effacer les ajouts quotidiens alors qu'il y a des choses que je veux y conserver.peut-être que si j'obtiens un deuxième emplacement pour les archives afin que les éléments quotidiens n'y soient pas ajoutés et que j'abandonne l'archivage complet et que je me débarrasse de certains éléments historiques, les archives pourraient être gardées sous contrôle.ou, peut-être que je pourrais obtenir plusieurs emplacements pour différents sous-ensembles du contenu archivé, cela créerait alors des dossiers GTX plus petits séparés ?
Aussi, je suppose que c'est le nombre de photos qui compte ?Mon rapport avec des images contient aujourd'hui un certain nombre d'images distinctes.Je pourrais améliorer les choses si je parvenais à faire moins de photos plus grandes ?
J'apprécie de savoir ce qui se passe, je peux peut-être essayer certaines choses pour l'améliorer.
Re : enregistrer html() lentement ?ceci est corrigé pour JMP 13.
Voici le problème : JMP crée un répertoire GFX au même emplacement que le fichier .html et, au fil du temps, le répertoire GFX devient assez volumineux à mesure que vous enregistrez davantage de fichiers .html.(Le GFX contient les images auxquelles le .html fait référence).Même si vous nommez les fichiers .html avec des noms différents, le même GFX est utilisé.Donc vous pouvez avoir de nombreux fichiers .html qui dépendent du contenu du GFX .
Ou bien, vous ne pouvez avoir qu'un seul fichier .html et de nombreuses images restantes et inutilisées dans le répertoire GFX.Si c'est le cas, supprimez le GFX (ou peut-être mettez-le à la poubelle, juste au cas où.) JMP sera beaucoup plus rapide la prochaine fois.Relisez le texte en gras ci-dessus avant de supprimer le GFX.
(JMP 12 et versions antérieures n'utilisent pas un bon algorithme pour rechercher les noms de fichiers inutilisés dans GFX... JMP 13 a une approche différente.)
