The splendour and poverty of the PLO - page 3
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
Actually, it wasn't the compiler that was being tested, but two methods of solving the same problem. It doesn't matter how the refrigerator hums, it's how it freezes.
It's a thrown-away problem and it's noisy...
Virtual functions are never inline, so with optimization enabled there's no point in comparing with simple examples if the switch is done well. That's one.
Who said that OOP is faster? More convenient, more logical, but hardly faster. That's two.
If you don't like it, don't use it.
After that there were two more variants of testing, 2 - with non-empty functions, 3 - with unique functions, the results were similar. Variant 1 was still conducted in C#, but the result was the opposite.
I have seen these options. And they, too, fit into the inline scheme and are well optimised.
The variant with C# shows another misleading error due to misunderstanding of the code optimizer's work. The code was not shown and the dotnet compiler also has several times more optimization methods that crack the degenerate cases of the test samples like nuts. I just gave you an example of a simple case of converting a virtual function into a regular function in simple cases. We will have this optimization (in simple cases like this test) enabled too and you too will see how a "virtual" method suddenly overtakes a straight one.
A thrown out of whack problem and noise...
Virtual functions are never inline, so with optimization enabled there's no point in comparing with simple examples if the switch is done well. That's one.
Who said that OOP is faster? Easier, more logical, but hardly faster. That's two.
If you don't like it, don't use it.
Well, it's not a problem at all. It's just an experiment with the results and a conclusion.
I like it, I don't like it. Using slow instead of fast is not logical.
I have seen these options. And they, too, fit into the inlining scheme and are well optimised.
The variant with C# shows another misleading error caused by misunderstanding of the code optimizer's work. The code was not shown and the dotnet compiler has several times more optimization methods that can crack degenerate cases of test examples like nuts. I just gave you an example of a simple case of converting a virtual function into a regular function in simple cases. We will have this optimization (in simple cases like this test) enabled too and you too will see how a "virtual" method suddenly overtakes a straight one.
It seems that whatever result I get will be wrong and misleading.
- For what?
- Indian, sir.
(xf Lone Ranger)
As much as I've tried, there's no way to get it to work slower than the virtual method via switch. Tried to, but sorry, it didn't work.
Here in the appendix is the first C# test. Here were the results
The evidence will come from the other side. Or again just words.
By and large, I'm only interested in facts.
Although I already know that OOP is slower, but it provides quite concrete conveniences
The evidence will come from the other side.
Proof of what?
Why do you need OOP to write toys? )
In any case, it is good that the issue has been raised.
We are constantly working on improving the compiler and its optimizer. We will now concentrate on optimizing virtual method calls (many virtual methods can be turned into direct methods).