Running the Overriding vs. Command if-statement

I am expanding and improving the Java application , which also performs long searches using a small DSL (it is used in detail for Model-Discovery, but it is generally NP-Complete).

During this search, I want to show a small progress bar on the console. Due to the general structure of DSL, I cannot calculate the total size of the search space. Therefore, I can only infer the course of the first backtracking statement.

Now the question is: I can use the flag for each backtracking statement to indicate that this statement should report progress. When evaluating the statement, I can check the flag using the if statement:

public class EvalStatement { boolean reportProgress; public EvalStatement(boolean report) { reportProgress = report; } public void evaluate() { int progress = 0; while(someCondition) { // do something // maybe call other statement (tree structure) if (reportProgress) { // This is only executed by the root node, ie, // the condition is only true for about 30 times whereas // it is false millions or billions of times ++progress; reportProgress(progress); } } } } 

I can also use two different classes:

  • Class that does nothing
  • Subclass that concludes

It will look like this:

 public class EvalStatement { private ProgressWriter out; public EvalStatement(boolean report) { if (report) out = new ProgressWriterOut(); else out = ProgressWriter.instance; } public void evaluate() { while(someCondition) { // do something // maybe call other statement (tree structure) out.reportProgress(progress); } } } public class ProgressWriter { public static ProgressWriter instance = new ProgressWriter(); public void reportProgress(int progress) {} } public class ProgressWriterOut extends ProgressWriter { int progress = 0; public void reportProgress(int progress) { // This is only executed by the root node, ie, // the condition is only true for about 30 times whereas // it is false millions or billions of times ++progress; // Put progress anywhere, eg, System.out.print('#'); } } 

Now really the question (s):

  • Is searching in Java a method faster than calling an if statement?
  • Also, will the interface and two independent classes be faster?

I know that Log4J recommends putting an if-statement around log calls, but I think the main reason is to build parameters, espacially lines. I have only primitive types.

EDIT : I clarified the code a bit (which is often called ... using a singleton doesn't matter here).

In addition, I did two long-term searches of the search, where the if statement, respectively, was called the operation call 1.840.306.311 times on the machine, doing nothing:

  • if version took 10h 6min 13sek (50.343 hits per second)
  • Version or took 10h 9min 15sek (50.595 hits per second)

I would say this does not give a real answer, because the difference of 0.5% is in measurement.

My conclusion: they more or less behave the same, but the basic approach can be faster in the long run, as Kane suggested in the answers.

+4
source share
5 answers

The only way to really answer this question is to try and profile the code under normal circumstances. There are many variables.

However, if I were to guess, I would say the following:

In general, an if statement is compiled to less bytecode than a method call, but with JIT compiler optimization, your method call can be inserted, which is not bytecode. In addition, with branch prediction of the if statement, the cost is minimal.

Again, in the general case, using interfaces will be faster than testing if you have to report every time the loop starts. In the long run, the cost of loading two classes, one-time testing and instantiation, will be less than performing a particular test eleven times four times. In the long run.

Again, the best way to do this would be to profile the code with real-world examples in both directions, perhaps even reporting the results. However, I can hardly see that this is a bottleneck for your application ... your time is probably better spent on optimizing elsewhere if speed is a concern.

+1
source

I think this is a definition of over-optimization in a text book. You are not even sure that you have performance problems. If you do not make MILLIONS of calls in this section, they will not be displayed in your hotspot reports if you profile them. If statements and method calls have a nanosecond execution order. Therefore, for the difference between them, you are talking about saving no more than 1-10ns. In order for it to even be perceived by a person as slow, it should be on the order of 100 milliseconds, and even if they pay attention to active pressing, etc. If they look at an indicator of progress, then they are not even noticing it.

Let's say we wanted to see if another extra time was added, and you found that one of them could save 10 ns (this probably looks like a saving of 1-4 ns). So, this would mean that you would need this section, which would be called 100,000,000 times, to save 1 s. And I can guarantee that if you have 100 million calls, you will find 10 other areas that are more expensive than choosing there or polymorphism. It seems foolish to speculate on the merits of 10ns in case you can save 1s, right?

I would be more worried about using singleton than performance.

+5
source

I would not worry about this - the cost is very small, the output to the screen or the calculation will be much slower.

+2
source

I would suggest that finding a method is faster than evaluating if (). In fact, also the version with if requires a method search. And if you really want to squeeze every bit of performance, use the private final methods in ProgessWriter , since this can allow the JVM to embed the method so that there is no method search, and even call the method in machine code obtained from byte code after the final compilation.

But perhaps they are both pretty close in performance. I would suggest checking / profile, and then focus on real performance issues.

+1
source

Putting something on the monitor is several orders of magnitude slower than any choice. If you really have performance issues (which I doubt), you need to reduce the number of calls to print .

+1
source

Source: https://habr.com/ru/post/1379008/


All Articles