How to Clean up After Script Exits?

[z11]

I am writing data out to a file within Main()...but how do I keep this file open (without f.close() during each iteration) for as long as the script is active and how would I clean up after a script exits, such as cleaning out global values, close files, etc.
I assume there are 3 ways for a script to exit:
1) reload
2) remove
3) the chart hosts the script gets closed.

Any advise would be greatly appreciated. Thanks.

[Doji3333]

A little help...

First, I would not suggest keeping the file open thru the instance of your EFS script. I suggest you OPEN/CLOSE the file each time you need to read/write from/to it. This is the safest way to handle files.

To remove global variables, use removeGlobalVariable("variablename"); You'll need to remove all of the previously instanciated global variables you've created with this script.

As you build your script and build the global variables, I suggest you let the EFS files that create the global variables control them - for example, if I have EFS1 that creates 4 global variables (for use with another EFS), I would let EFS1 REMOVE them when it unloads (using POSTMAIN).

In my opinion, this is the best way to handle your requests.

B

[z11]

Thanks Brad...2 questions:
1) I have not been able to find any reference on POSTMAIN...is that a separate function? like PreMain? how to use it?
2) I just thought it would be a lot of disk I/O if for every iteration in Main the file is opened and closed ...what if there are alot of files and many scripts? I was wondering if there is indeed a mechanism to keep a file open in Main() and close it in POSTMAIN?

Thanks again.

[Doji3333]

more help..

Yes, postMain() is a function (like preMain())..

you would declare it as..

function postMain() {

}

You could just as easily leave the f.close() function off of your file functions, but remember - you'll have to develop control variables to know you've opened the files and left them open.. I have not tried this because I do not want to risk unterminated file markers on my system.

I think the access of writing to a file would not be much of a problem. If you are going to do it on each tick or on each bar - you're really talking about every few minutes (or so).

Speaking from experience, the trick is to keep your files small enough to do what you want and not let them get HUGE.

Your choice though..

B

File I/O can be extremely time consuming if you perform too often. As Brad indicated, if used in moderation, it is alright, however if used excessively, it can really slow down your system.

I performed a test recently where I opened a file, wrote several records and then closed the file 5,000 times. Here are the results:

Elapsed time = 3.040000000000191 (min)

5000 iterations of 

file1.open("at+");
file1.writeln(record);
file1.close(); 

Then I tested an alternate means of keeping the file open, then closing the file in post main.

elapsed time = 0.009999999999990905

5000 iterations of
file1.writeln(record);

The file was opened,  iterated 5000 times and closed in post main

The downside was that the last line of the data stored in the file was not written til post main 

Finally, I tested another alternate method which involved keeping the file open, then using the flush() command, (thanks Garth Doverspike), then closing the file in post main. This was the best alternative in my opinion

Elapsed time = 0.010000000000218279
Elapsed time = 0.010000000000218279

5000 iterations of
file1.writeln(record);
file1.flush();

The file was opened,  iterated 5000 times and closed in post main

This time, the last line of the data stored in the file was written 

I tested this last method several ways. One way I did not close the file in post main. The other time I did close it in post main. Performing either way, the data was accessible and had all the data in the file. This is a positive, since in the event of a system crash, all the data would be saved. The secret is using the flush() command.


The step I use in post main is as follows

if(file1.isOpen())file1.close(); 

[z11]

wow thanks Steve...that was one incredible reply!! I implemented your suggestion and is working fine.

z11,

You are welcome, the timing was perfect, I just completed testing these different methods in the last month.