Loading Igor Procedures- speed and memory
jeremypmeyers
I assume that there's a slight penalty on the time that it takes to launch Igor, but does a large number of functions in the Igor Procedures window have subsequent penalties on either speed or memory usage?
If there is a penalty, is there a way to conditionally #include some functions depending upon which tasks the user wants to perform? I'd like to have a common front end that all users experience that allows them to perform any of the automated analyses that my team and I have written, but if there's a problem with pre-loading every function that they might want to use, I'm not sure how to write a procedure that just includes the .ipf files that the user needs.
It takes time to compile the procedures. Whether it takes enough time to be a problem depends on how many procedure files you have loaded, how long they are, how fast your machine is, and how patient you are.
I recommend that you assume that it is not a problem. If it becomes a problem, you can look into loading and unloading packages as the user requests them. I wrote a simple demo of this but it appears to be broken. If you need it, I will try to get it to work and then post it.
May 13, 2016 at 04:50 pm - Permalink
I might suggest a few changes to your approach. First, use the User Procedures folder exclusively, not the Igor Procedures folder. Secondly, have one master pxp or ipf file (e.g. Master.pxp or Master.ipf) that users put in the User Procedures folder. The advantage of Master.pxp is, it gives one place where the user clicks to start. The disadvantage is, users can mistaken overwrite that pxp ... you should program an immediate SaveAs directive at startup to avoid this mistake. The advantage of a Master.ipf is, it is called by an #include directive in a user procedure and therefore remains separate from the user's own experiment (and is less prone to be accidentally overwritten). The disadvantage is, you have to tell users to put the #include Master.ipf comment in their experiments each time. Regardless of the choice ipf of pxp, inside the procedure file for the Master package, put the #include directives that are needed for your common front end. Also put the #include directives for each segment of the analysis that you want to provide. Finally, as best possible, make each segment of the analysis you want to provide in to an independent module. This way, it loads and compiles only once, regardless of what the user does to the overall experiment.
I took this approach many (many) years ago with SpXZeigR. It had baseline routines, peak fitting routines, smoothing routines, ... each in their own sub-folder in the main folder. The starting point was to use #include SpXZeigR as a directive.
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
May 14, 2016 at 08:06 am - Permalink
May 19, 2016 at 06:32 am - Permalink
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
May 19, 2016 at 08:48 am - Permalink
May 19, 2016 at 09:45 am - Permalink
May 19, 2016 at 10:41 am - Permalink
May 19, 2016 at 11:58 am - Permalink
May 19, 2016 at 12:03 pm - Permalink
May 19, 2016 at 12:51 pm - Permalink
Look for command help on the Save command. The last line has a link to descriptions of how to import and export data. Here's a function call to start.
wave ww
Save ww
return 0
end
It only gets easier after this depending on where and how you want to save the wave. :-)
--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
May 19, 2016 at 02:27 pm - Permalink
May 19, 2016 at 05:37 pm - Permalink