save html() slow?

[#1]

When I use save html() on a report window it takes a VERY long time to save- can be a half a hour or more for a single page.  It does work in the end.  Do others have this issue?

Is there anything I can do to make it faster?  these aren't large files - 2-5 K only.  What is it thinking about?  I want to do this as part of an automatic job so a lone report taking a half hour is actually OK but one of the cases is one where I want to loop over many different cases creating this output so it can really take too long and the job can get terminated.

I use saveinteractivehtml() in some other cases and do not have this issue even though the files are larger.  If I use saveinteractivehtml on this same window it is also fast  but this is a window that saveinteractivehtml does not render nicely.   I have certain outputs I can't use that with..

I have this issue with at least 2 quite different windows - one is made up of JMP plots, the other is mainly images with some annotations created in JMP.

appreciate any suggestions on what to try.

[#2 · Accepted solution]

this is fixed for JMP 13. 

Here's the problem:  JMP creates a GFX directory in the same location as the .html file, and over time, the GFX directory gets quite large as you save more .html files.  (The GFX holds the images the .html refers to).  Even if you name the .html files with different names, the same GFX is used.  So you may have many .html files that depend on the content of the GFX.

Or, you may only have one .html file and a lot of leftover, unused pictures in the GFX directory.  If so, delete the GFX (or maybe put in trash, just in case.)  JMP will be much faster next time.  Re-read the bold text above before you delete the GFX.

(JMP 12 and earlier is not using a good algorithm for finding unused file names in the GFX...JMP 13 has a different approach.)

[#3]

So, just to verify, if my plan was to create a growing archive with a new page for each widget through our factory, for example, that is doomed to get slower and slower. But where I have pages that overwrite themselves every day I could clear out the images from previous days periodically as they are no longer used and that file could stay small. I might automatically delete it early in the am before all the reports update and when nobody will complain that the page is broken.....

I have some of each type which is maybe worst case as I can't easily clear out the daily additions while there are things I want to keep in there.  maybe if I get a second location for the archive so it's not getting the daily stuff added to it and I give up full archiving and get rid of some historical stuff the archive could be kept under control.  or, maybe I could get multiple locations for different subsets of the archived content then it would make separate smaller gtx folders? 

Also, I take it that it's the number of pictures that matters?  My report with images has a number of separate images today.   I might improve things if I managed to make fewer larger pictures?

Appreciate knowing what's going on, maybe I can try some things to improve it.

[#4]

Yes.  As the number of pictures grows, it takes much longer to add another picture.  Loading the HTML is not a problem, but writing is.  JMP 13 will use part of the date in the file name to prevent the slow down.

Something like this will work better, and keep the gfx+html organized at the same time. The last few lines are suggesting a way to keep the current file in a consistent location for your users:

// example script to make a daily report folder

dt = Open( "$sample_data/big class.jmp" );

rpt = dt << Bivariate( Y( :weight ), X( :height ), Fit Line( {Line Color( {213, 72, 87} )} ) );

// directory names can be all numbers, but you might want a letter,

// R for report, perhaps, as the first letter.  Or a better title.

// make sure the date format doesn't have / or \ characters!

// the YYYYMMDD format is nice because it sorts correctly

daily = "R" || Format( Today(), "yyyymmdd" );

pathname = "$desktop/" || daily;

If( !Directory Exists( pathname ),

       Create Directory( pathname )

);

rpt << savehtml( pathname || "/biv.html" );

rpt << closewindow;

Close( dt, "nosave" );

Create Directory( "$desktop/FinalLocation" ); // probably already there from yesterday

Copy Directory( pathname, "$desktop/FinalLocation" ); // using daily

Delete Directory( "$desktop/FinalLocation/current" ); // clean out yesterdays report

// make daily "R20160527" be a fixed name, "current"

Rename Directory( "$desktop/FinalLocation/" || daily, "current" );

[#5]

Thanks!  I see I can definitely improve on what I have at least.

[#6]

Just in case it helps anyone else I found a solution for my archiving case too:

The report in question works well to just be one big picture even though JMP was saving over 40 separate pieces for each page so I can replace nw<<savehtml() with nw<<savepicture().  that lets me save in a location of my choosing with a name of my choosing.  Then I can also save an html  - it's just a few lines of text for one that just displays an image from a specified location and a link back to my directory page.  With only one picture per file and it being easy to change the location of the pictures in concert with the html text that calls for them by location I can keep them organized in reasonable size folders.  Also, I think I can handily leave my existing archive of pages alone.  The directory just points at the huge gfx folder for the old ones but I don't have to write there any more so appears there is no harm in that having having some tens of thousands of pictures in it.

Probably for certain reports savehtml() does a lot of heavy lifting and creates some complex html but for this non-interactive report it's really quite easy to DIY the html using a single image and controlling all the file names and locations myself.