The splendour and poverty of the PLO - page 6
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
He showed that direct call or virtual call have no effect in real projects.
The vast majority of costs are incurred in calling system functions where MQL programs spend almost all their time. The costs of arranging the calls are negligible compared to the payload.
Where did he show? Is a table with some function names and measurements an argument? We are not telepathic experts here. You need to see the code of functions, and then you can say something.
Where did he show it? A table with some function names and measurements - is that an argument? We're not telepathic experts here. You need to see the code of functions, then we can talk about something else.
He showed that in real projects, direct call or virtual call have no impact.
The vast majority of costs are incurred by system function calls, where MQL programs spend most of their time. The cost of arranging the calls is negligible compared to the payload.
+100 Yes, it does!
Moreover, I've noticed that when I had to rewrite the sprawling classes so that some of their functions were performed by other classes (inclusion/decomposition), the overall performance increased and control over the code increased. In other words, in practice, we see the opposite of what Integer and old-school C fans are trying to prove to us: the number of classes grows, the number of methods grows, and performance, on the contrary, grows.
Where did he show it? A table with some function names and measurements - is that an argument? We're not telepathic experts here. You need to see the code of functions, then we can talk about something else.
+100 Yes, that's right!
Moreover, I noticed that when I had to rewrite sprawling classes so that some of their functions were performed by other classes (inclusion/decomposition), the overall performance increased, and control over the code increased. In other words, in practice, we see the opposite of what Integer and old-school C fans are trying to prove to us: the number of classes grows, the number of methods grows, and performance, on the contrary, grows.
A new way of self-indulgence? Come on, come on.
Vasily, you should have read what I was trying to prove here, though (and whatever you think about it, proved it).
Note, however, that having the source code won't tell you anything. The cumulative complexity is not the same. Even after analyzing the sources you would say "well, something there is called, something is counted, something is taken from somewhere, but what exactly is not clear, so again nothing is proven.
In general, yes, you're probably right, individual functions probably won't tell you much. What's the point of even talking about your software if it's a pig in a poke for everyone else.
In fact, the main thing we are interested in is the total number of passages through virtual methods, and total time spent on it. Here in your table there is some shaded function executed 5 million times. I don't know what it is, maybe it's just a virtual method with the simplest action. However, 5 million is a trifle. I don't suppose you have any heavy calculations in your program, so there's nothing much to discuss. Suppose you were calculating a system of linear equations 30000x300000 and accessing matrix elements through virtual methods, there would be something to talk about.
A new way of self-influencing? Come on, come on.
Vasily, you should have read what I was trying to prove here, after all (and whatever you think about it, proved it).
Dmitry, I am neither for you nor against you. To understand it, you need to know the inner workings of the compiler inline, but to open this information for MQ is tantamount to help writing a decompiler.
Of those discussing here, only Renat has such information, so we have to rely on his word. I don't see any other way.
If he says that you're not setting the test correctly, you probably are.
The question is different, only MQ can set the test correctly in such a case, that is what needs to be done.
As they say test for test, my word against yours. And you are trying to prove the unprovable. It is impossible to prove or disprove your claims without having something to compare it to.
The decompiler is out of the question here.
You just need to understand and know the techniques of optimizing compilers to avoid testing simplified degenerate cases, which are brutally optimized and degenerate into linear code. We have released the fourth generation of compilers for a reason.
This is exactly what we are talking about.
For example, if we were calculating a system of linear equations 30000x300000 and access to matrix elements was through virtual methods, there is already something to talk about.
In such cases, the first refactoring would give you a hundred-fold speed gain. And the virtual call would be ranked tenth in terms of costs.
That is, the example is unrealistic.
Let's write everything in assembly language then. It would be faster anyway.
I don't understand the problem. I have never seen an Expert Advisor or indicator with 1 MB of code.
The call of any function also takes some time. Let's give up functions as well!
Control over large projects is much more convenient with OOP.
Also, code execution speed is very often not as critical as pinging time to broker and response to broker's order.
Check out the HFT algorithms. They require maximum speed, but you won't find any complex calculations there.
PS. You don't usually need a supercar or a snowmobile to get from point A to point B. A moped is enough! A moped is enough!