MT5 RAM memory voraciousness, problems with reading/writing large files - page 7

 
Turns out that my terminal without the script is eating up 820mb, so the binary is eating up 180 megabytes, which is apparently fine, given the two filled arrays.
 
The topic is not quite correctly worded.

The memory is not eaten up by the terminal, but by a specific programme with a specific implementation. In this case, the MQL program is storing data incorrectly and inefficiently.
 
Aleksey Vyazmikin:

Can you tell me what to fix in it?

Well, it's okay that you read the array first, but after you read it, you have to close the file.

and then write the same way, not through your library.

 
Renat Fatkhullin:
The topic is not quite correctly formulated.

The memory is not eaten up by the terminal, but by a specific programme with a specific implementation. In this case, the MQL program is storing data incorrectly and inefficiently.

The topic was formulated at the time the problem arose, when there was no final understanding of the causes. I proceeded from the fact that I have a class that was created with the involvement of an MQ employee, which means I had no reason to doubt its correctness.

If the program is not storing the data correctly and efficiently, can you tell me how to store it correctly and efficiently? What should I change in the class to make it consume less memory?

In general, it would be very nice if the terminal was delivered with similar class to work with tables based on CSV.

 
Maxim Dmitrievsky:

It's okay to read the array first, but after reading the file you have to close it

and write the same way, not through your library.

I will close it, thank you.

I have to write in two variants, because CSV format helps me to really see what's going on in the arrays - alas, I make mistakes and therefore I'd rather recheck calculations in excel when debugging the code, than to make wrong conclusions later.

 
Vladimir:

What have you learned from the documentation about the third parameter that is useful for this case, when solving the problem of lifting into memory .csvs created in different programs and having arbitrary size?

Feel free to suggest a better, non-binary change, which increases the speed of memory reallocation (reducing the number of ArrayResize calls) more than a binary search...

Free lesson for beginners:

The third parameter ArrayResize specifies the actual size of the array, a multiple of that number.

ArrayResize(arr, 5, 1000) - will take 1000 elements in memory.

ArrayResize(arr, 1005, 1000) - will take up 2000 elements in memory.

That's why there's no permanent memory allocation.

 
Aleksey Vyazmikin:

The topic was formulated at the time the problem arose, when there was no definitive understanding of the causes. My assumption was that I have a class that was created with input from an MQ employee, which means I had no reason to doubt that it was working correctly.

If the program is not storing data correctly and efficiently, can you tell me how to store it correctly and efficiently? What should I change in the class to make it consume less memory?

In general, it would be very nice if the terminal was delivered with such a class to work with tables based on CSV.

The problem is not in the class, but in using this class.

In fact, reading from CSV is already implemented at FileOpen level with flag FILE_CSV.

You don't need a whole separate class for this.

 
Roffild:

A free lesson for beginners:

The third parameter ArrayResize sets the actual size of the array to a multiple of this number.

ArrayResize(arr, 5, 1000) - will take up 1000 elements in memory.

ArrayResize(arr, 1005, 1000) - will occupy the memory of 2000 elements.

That's why there is no permanent memory allocation.

Vladimir, unlike you, managed to analyze the code and find a way to speed it up. And you are positioning yourself here as a theorist who cannot deal with somebody else's code. All these conclusions - what do they give you, maybe you can show that adding additional parameters will speed up the code or reduce memory consumption?


Roffild:

The problem is not in the class, but in how the class is used.

In fact, reading from CSV is already implemented at FileOpen level with flag FILE_CSV.

You don't need a whole separate class for that.

If you don't understand what it is for, why are you making decisions for others? I'm saying you have to make it convenient for people, that's what classes are written for.

 
Aleksey Vyazmikin:

Vladimir, unlike you, was able to analyse the code and find a way to speed it up. And you are positioning yourself here as a theorist who cannot work with other people's code. All these conclusions - what do they give you, maybe you can show that adding additional parameters will speed up work or reduce memory consumption?

Actually Vladimir couldn't make the class faster by editing it. The class was created by an "MQ employee" and a user who didn't read the documentation managed to improve the class?

Aleksey Vyazmikin:

If you don't understand what it's for, why are you deciding for others? I say that you have to make it convenient for people, that's what classes are written for.

So in order to use standard functions, do you have to wrap them in classes?

Maybe you should read documentation on FILE_CSV, instead of using a whole separate class?

There have already been other ready-made solutions posted here that have been ignored.

My solution for writing to CSV with no limit on the number of columns is in my library. Even the principles of OOP (I don't think you're familiar with this programming method) are respected. But I won't recommend it.

It's unlikely that the right solution will appear here for free...

 
Roffild:

Actually, there is no way Vladimir could have accelerated the class with his edits. The class was created by an "MQ employee" and the user, who didn't read the documentation, managed to improve the class?

Did you check and no acceleration was detected? Or are you saying that I am misleading everyone here?

Roffild:

So to use standard functions, do you have to wrap them into classes?

Maybe you should read documentation on FILE_CSV instead of using a whole separate class?

There have already been other ready-made solutions posted here that have been ignored.

My solution for writing to CSV with no limit on the number of columns is in my library. Even the principles of OOP (I don't think you're familiar with this programming method) are respected. But I won't recommend it.

A free solution is unlikely to appear here...

Do you read this thread carefully? Have you seen my answer to the ready solution in the form of a function? Do you have another solution? Of course, I don't know what OOP is, a careful reader of this thread would have noticed it at once...

About profitability/free - that's ridiculous, I was just showing that paid solutions don't make a solution better than a free one, while you are talking about money again...