You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
"When you close a file, the data is automatically reset to disk, so there is no need to call FileFlush() before calling FileClose()" - Yes, yes, I'm starting to see whatsergeev was talking about. So, it turns out that instead of FileClose() you can call FileFlush() to guarantee saving the last record to the file? And this would be a smart solution?
not instead of, but by necessity.
Flush - resets the remaining data, and does NOT close the file. This is what you want, right?
Close- resets the rest of the data to disk and closes.
not instead of, but by necessity.
Flush - resets the remaining data, and does NOT close the file. This is what you want, right?
Close - flushes the remaining data to disk and closes.
Something about time minimization using FileFlush() doesn't work very well:
2011.05.29 21:58:20 FlushSave (EURGBP,M1) FileFlush. GetTickCount() = 133766
2011.05.29 22:00:33 FlushSave (EURGBP,M1) FileClose. GetTickCount() = 133734
In fact, it takes the same amount of time for both functions to work.
As I understood this line moves position to the beginning of file without offset. This allows to overwrite existing information (i.e. the date is updated, but it does not accumulate in the file).
By using move to end of file instead of SEEK_SET, the data would pile up in the file.
You open a new file handle every time you flush. What for? And you don't close it by the way.
The advantage of the FileFlush function is that you don't need to reopen the handle.
1. As I understand it, this line moves the position in the file without offset. This allows existing information to be overwritten (i.e. the date is updated but does not accumulate in the file)
Thus, if used instead of SEEK_SET skip to the end of file, data will be accumulated in the file.You open a new file handle every time you flush. What for? And you don't close it by the way.
The advantage of the FileFlush function is that you don't need to reopen the handle.
I did it like this:
Result:
2011.05.29 23:14:31 FlushSave (EURGBP,M1) FileFlush. GetTickCount() = 13563
2011.05.29 23:14:32 FlushSave (EURGBP,M1) FileClose. GetTickCount() = 531
Swapped the lines, according to documentation:
But I don't understand the point of calling FileFlush() before FileWrite().I did it like this:
Result:
2011.05.29 23:14:31 FlushSave (EURGBP,M1) FileFlush. GetTickCount() = 13563
2011.05.29 23:14:32 FlushSave (EURGBP,M1) FileClose. GetTickCount() = 531
I swapped the lines, according to documentation:
But the point of calling FileFlush() before FileWrite() has yet to be understood.Here is the variant:
The result is FileFlush. GetTickCount() = 26125
Here is the variant:
The result is FileClose. GetTickCount() = 3969This option gave a result between 47 and 110
1. Conclusion - Using FileFlush in a loop slows down execution by about 260 times.
2. A loop for 50,000 records in this variant has the following result - FileFlush. GetTickCount() = 1891.
3. I failed to kill the terminal when executing the 50000-write cycle without exiting the file (I closed the terminal and "killed" the process).
4. I was able to kill terminal with 100000 loop, and the file had more than 65536 records (so much space in Excel 2003).
I swapped the lines according to the documentation:
Where does it say so in documentation?
How can you make sense of something that doesn't have one? Return the string order and double-check it. Apparently the documentation did not express it correctly.
But... Thanks to your tests, the bug seems to have been detected - FileFlush seems to eat up an inordinate amount of time when no changes are made.Interesting:
OMG! It's where the inference is that it's a morass. This is how claims like "OOP is faster" or "indicators are slow, we should move the whole code to the Expert Advisor" appear.
Expert, write down how to use this function correctly.
Hypothetically so:
I.e. it is correct to compare FileClose -- FileOpen bundle with FileFlush.
Theoretically, FileFlush should be a part of FileClose and could not be slower than the bundle.
There is no point in flushing changes before they appear because they are not there yet :)
But, despite the wild conclusions, the tests are indicative, so we wait for comments from developers on how the function works when there are no changes.