html() langsam speichern?<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />Wenn ich save html() in einem Berichtsfenster verwende, dauert das Speichern SEHR lange – für eine einzelne Seite kann es eine halbe Stunde oder länger dauern.Es funktioniert am Ende.Haben andere dieses Problem?
Kann ich irgendetwas tun, um es schneller zu machen?Dies sind keine großen Dateien – nur 2–5 KB.Woran denkt es?Ich möchte dies als Teil eines automatischen Jobs tun, sodass ein einzelner Bericht, der eine halbe Stunde dauert, eigentlich in Ordnung ist. In einem Fall möchte ich jedoch viele verschiedene Fälle durchlaufen, um diese Ausgabe zu erstellen, sodass es wirklich zu lange dauern kann Der Job kann beendet werden.
In einigen anderen Fällen verwende ich saveinteractivehtml() und habe dieses Problem nicht, obwohl die Dateien größer sind.Wenn ich saveinteractivehtml für dasselbe Fenster verwende, ist es ebenfalls schnell, aber dieses Fenster wird von saveinteractivehtml nicht gut dargestellt.Ich habe bestimmte Ausgänge, mit denen ich das nicht verwenden kann.
Ich habe dieses Problem mit mindestens zwei völlig unterschiedlichen Fenstern – eines besteht aus JMP-Diagrammen, das andere besteht hauptsächlich aus Bildern mit einigen in JMP erstellten Anmerkungen.
Ich freue mich über Vorschläge, was Sie ausprobieren sollten.
Betreff: HTML() langsam speichern?Nur für den Fall, dass es jemand anderem hilft, ich habe auch eine Lösung für meinen Archivierungsfall gefunden:
Der fragliche Bericht eignet sich gut als Gesamtbild, obwohl JMP über 40 separate Teile für jede Seite gespeichert hat, sodass ich nw<
Wahrscheinlich übernimmt savehtml() bei bestimmten Berichten viel Arbeit und erstellt einige komplexe HTML-Dateien, aber für diesen nicht interaktiven Bericht ist es wirklich ganz einfach, die HTML-Datei mit einem einzigen Bild selbst zu erstellen und alle Dateinamen und Speicherorte selbst zu steuern.
Betreff: HTML() langsam speichern?Danke!Ich sehe, dass ich zumindest das, was ich habe, definitiv verbessern kann.
Betreff: HTML() langsam speichern?Ja.Wenn die Anzahl der Bilder wächst, dauert es deutlich länger, ein weiteres Bild hinzuzufügen.Das Laden des HTML ist kein Problem, das Schreiben jedoch schon.JMP 13 verwendet einen Teil des Datums im Dateinamen, um die Verlangsamung zu verhindern.
So etwas funktioniert besser und sorgt gleichzeitig dafür, dass gfx+html organisiert bleibt. Die letzten Zeilen schlagen eine Möglichkeit vor, die aktuelle Datei für Ihre Benutzer an einem einheitlichen Speicherort aufzubewahren:
// Beispielskript zum Erstellen eines täglichen Berichtsordners
dt = Offen ( „$sample_data/big class.jmp“ ) ;
rpt = dt << Bivariat ( Y ( : Gewicht ) , X ( : Höhe ) , Linie anpassen ( { Linienfarbe ( { 213 , 72 , 87 } )} ) ) ;
// Verzeichnisnamen können alle Zahlen sein, aber vielleicht möchten Sie einen Buchstaben,
// R für Report, vielleicht als Anfangsbuchstabe.Oder ein besserer Titel.
// Stellen Sie sicher, dass das Datumsformat keine /- oder \-Zeichen enthält!
// Das Format JJJJMMTT ist schön, weil es richtig sortiert wird
täglich = "R" || Format ( Heute () , „JJJJMMTT“ ) ;
Pfadname = „$desktop/“ || täglich ;
Wenn ( ! Verzeichnis existiert ( Pfadname ) ,
Verzeichnis erstellen ( Pfadname )
) ;
rpt << savehtml ( Pfadname || „/biv.html“ ) ;
rpt << Fenster schließen ;
Schließen ( dt , „nosave“ ) ;
Verzeichnis erstellen ( „$desktop/FinalLocation“ ) ; // wahrscheinlich schon seit gestern da
Verzeichnis kopieren ( Pfadname , „$desktop/FinalLocation“ ) ; // täglich verwenden
Verzeichnis löschen ( „$desktop/FinalLocation/current“ ) ; // Bereinigen Sie den gestrigen Bericht
// Täglich „R20160527“ zu einem festen Namen machen, „aktuell“
Verzeichnis umbenennen ( „$desktop/FinalLocation/“ || täglich , "aktuell" ) ;
Betreff: HTML() langsam speichern?Um es noch einmal zu verifizieren: Wenn mein Plan darin bestand, beispielsweise über unsere Fabrik ein wachsendes Archiv mit einer neuen Seite für jedes Widget zu erstellen, wird das immer langsamer werden. Aber wo ich Seiten habe, die sich jeden Tag selbst überschreiben, könnte ich die Bilder von früheren Tagen regelmäßig löschen, da sie nicht mehr verwendet werden und die Datei klein bleiben könnte. Ich lösche es möglicherweise automatisch früh morgens, bevor alle Berichte aktualisiert werden und sich niemand darüber beschwert, dass die Seite kaputt ist.....
Ich habe von jedem Typ etwas, was vielleicht der schlimmste Fall ist, da ich die täglichen Ergänzungen nicht einfach entfernen kann, während es Dinge gibt, die ich behalten möchte.Vielleicht könnte das Archiv unter Kontrolle gehalten werden, wenn ich einen zweiten Speicherort für das Archiv erhalte, sodass ihm nicht die täglichen Inhalte hinzugefügt werden, und ich die vollständige Archivierung verzichte und einige historische Inhalte entferne.Oder könnte ich vielleicht mehrere Speicherorte für verschiedene Teilmengen des archivierten Inhalts erhalten, dann würden dadurch separate kleinere GTX-Ordner erstellt?
Ich gehe auch davon aus, dass es auf die Anzahl der Bilder ankommt?Mein heutiger Bildbericht enthält mehrere Einzelbilder.Könnte ich die Dinge vielleicht verbessern, wenn es mir gelänge, weniger größere Bilder zu machen?
Ich schätze es zu schätzen, zu wissen, was los ist. Vielleicht kann ich einige Dinge ausprobieren, um es zu verbessern.
Betreff: HTML() langsam speichern?Dies wurde für JMP 13 behoben.
Hier liegt das Problem: JMP erstellt ein GFX-Verzeichnis am selben Speicherort wie die .html-Datei, und mit der Zeit wird das GFX-Verzeichnis ziemlich groß, wenn Sie mehr .html-Dateien speichern.(Das GFX enthält die Bilder, auf die sich die .html-Datei bezieht).Auch wenn Sie die .html-Dateien mit unterschiedlichen Namen benennen, wird dasselbe GFX verwendet.Also Möglicherweise verfügen Sie über viele HTML-Dateien, die vom Inhalt des GFX abhängen .
Oder Sie haben möglicherweise nur eine .html-Datei und viele übrig gebliebene, unbenutzte Bilder im GFX-Verzeichnis.Wenn ja, löschen Sie das GFX (oder legen Sie es für alle Fälle in den Papierkorb). JMP wird beim nächsten Mal viel schneller sein.Lesen Sie den fett gedruckten Text oben noch einmal, bevor Sie das GFX löschen.
(JMP 12 und früher verwenden keinen guten Algorithmus zum Auffinden nicht verwendeter Dateinamen im GFX ... JMP 13 verfolgt einen anderen Ansatz.)
