SavePict speed

Share icon

HI All,

I have a lab tool that saves a picture image of a graph (as a png file) as well as two 8 meg raw data files as .ibw files. My users notice that the save operation takes quite a while (about 12 sec). The system is a PC running 6.2 on Windows XP Service Pack 3 (Quicktime is installed)

In my investigation it seems as that the SavePict operation is a major culprit in the time.

I use SavePict/e=-5 (+ some path and name strings) in the function.

If I select "Save Graphics" from the file menu and after selecting the file type it takes a good 5-6 sec before the file dialog box appears.

As a test on my Mac laptop it is very fast.

Is this normal on a PC? And if not is there anything I can do to speed this up?

Thanks.

Andy
Are you saving to a local drive or a network drive? Saving to a network drive is likely to be slower than saving to a local drive. Also, are there any external drives (USB drives) attached to the PC? I've seen delays on both Windows and Macintosh when a Save as/Open dialog is first presented because the OS has to communicate with the external drives and that can take a few seconds.

You didn't say how large the image is. If it's very large, then saving could be slow.

December 2, 2010 at 08:30 am - Permalink

In my function it is saving to a network drive and I am using a path to define the location on the shared drive.

There are no external drives attached to the PC. I have tried saving to the local drive by changing the defined path to a local folder, but to no avail; it still took 5-6 seconds to save.

If I do the "Save Graphics" command manually via the command line (i.e. not in my function), it takes about 5-6 seconds for the file name dialog box to show up. So my question is after the "Save Graphic File" dialogue box is dismissed with path being "_use_dialog_" it takes the 5-6 seconds for "Write Graphic AS:" dialog to come up: Is all that time just due to Windows having to resolve network share location... or is does the image get written in the defined format in that time also?

The graph is relatively large and I can check if making the window smaller is beneficial.

December 2, 2010 at 08:25 pm - Permalink

So it sounds like your problem is just that it takes a while for the dialog to come up, not that the saving of data itself is slow, right? If so, I wouldn't be at all surprised if this is due to having shared network drives. It's easy to test this--just disconnect all the shared drives and see how long it takes. I don't think that Igor should be doing much when the dialog is being opened that would account for the slowness.

December 3, 2010 at 10:08 am - Permalink

I believe the picture is generated before the dialog is displayed and that accounts for the time before the dialog, or at least most of it.

December 3, 2010 at 12:20 pm - Permalink