Overhead for the PLO
What kind of overhead are we talking about?
If we're talking about machine code, then as far as I know, the virtual function calls the procedure indirectly, through the virtual function table. But in case of normal functions it's a direct call. I think there is very little overhead.
Programmer overhead is much more important - code writing and maintenance, bug fixing...
Functions without parameters are faster than functions with parameters.
Functions without parameters are faster than functions with parameters.
Of course, I've been banging on in assembler for 2 years )) True, for embedded processors, but C++ is always C++. Even a function without parameters has a prologue and an epilogue, which also takes time.
The fastest way, of course, is to use a macro designed to look like a function. It's a pity that there are no inline functions in MQL, but macros are a substitute for
What kind of overhead are we talking about?
If we're talking about machine code, then as far as I know, the virtual function calls the procedure indirectly, through the virtual function table. And in case of normal functions it's a direct call. I think there is very little overhead.
Programmer's overhead is much more important - code writing and maintenance, error correction...
Of course, we don't care about the execution time overhead and extra kilobytes. We don't care about those extra kilobytes.
A macro would of course be the quickest.
Rinat said that MT - a serious inliner works, and gives good results.
Yes, according to my personal observations, in MT4 the inliner's work depends on the stack size (memory allocated for variables in the stack) and the number of variables.
But in MT5 the dependence on the stack size seems to be removed and the optimizer is more assistant there in general.
In connection with a resource-intensive task, a question has arisen - what is the overhead of using OOP compared to conventional procedural programming.
Has anyone done such tests?
I'm interested in the difference between:
- Function call with parameters
- Function call without parameters
- Macro call with functionality of the above function
- Function call - method of a class
- Virtual function call
If ready-to-use OOP libraries are available, this reduces the application development time. The speed of execution may slow down when calling the virtual function.
The only nuance is the availability of good OOP libraries.
"Standard library" violates my sense of beauty and makes me go to DLL and quietly code in C++
Rinat said that in MT - a serious inliner works, and gives good results.
Yes, the inliner is very aggressive and automatic.
The x64 code optimizer is also a head above the 32-bit version (this branch is completely stopped and not developed). In addition, the x64 optimizer knows how to unroll most virtual functions into direct and inline calls. After all, virtual functions are often degenerate.
But where the real overhead is in reference operations and controlling dynamic indexes. They have to be controlled all the time.
In connection with a resource-intensive task, a question has arisen - what is the overhead of using OOP compared to conventional procedural programming.
Of course, the nice features of OOP are costly in resources and time-consuming debugging. OOP makes sense only as a convenient text wrapper or in case of minimal use in runtime initialization... Actually, OOP was just a marketing thing from Microsoft to increase the costs of programmers' working hours and to stimulate the purchase of more advanced equipment. And they are not fools themselves and write all the software in C and assembler.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
In connection with a resource-intensive task, a question has arisen - what is the overhead of using OOP compared to conventional procedural programming.
Has anyone done such tests?
I'm interested in the difference between: