Java transaction costs

Is there any reason to say how expensive the operation is for the processor in milliseconds or on the flop? I would be interested in "instanceof", casts (I heard that they are very "expensive").

Is there any research about this?

+6
source share
4 answers

This will depend on which JVM you use, and the cost of many operations can vary even within the same JVM, depending on the specific situation and the degree of JIT optimization.

For example, a call to a virtual method can still be built into the Hotspot JIT - if it has not been overridden by anything else. In some cases with a JIT server, it can still be embedded with a quick type test for several types.

In principle, JITs are quite complex, which is unlikely to make sense for a general answer to the question. You should compare your own situation as with the real world as soon as possible. Usually you should write code with the primary goals of simplification and readability, but regularly evaluate the effectiveness.

+8
source

The time when counting instructions or loops can give you a good idea of ​​the performance of any code is long gone, thanks to the many optimizations that occur at all levels of software execution.

This value is especially for VM-based languages, where the JVM may just skip some steps because it knows that it is not necessary.

For example, I read some time ago in an article (I will try to find and relate it to time) that these two methods are pretty much equivalent to cost (in the JVM HotSpot):

public void frobnicate1(Object o) { if (!(foo instanceof SomeClass)) { throw new IllegalArgumentException("Oh Noes!"); } frobnicateSomeClass((SomeClass) o); } public void frobnicate2(Object o) { frobnicateSomeClass((SomeClass) o); } 

Obviously, the first method works more , but the JVM knows that the type o has already been marked in if and can actually skip the cast check type later and make it non-op.

This and many other optimizations make counting "flops" or cycles almost useless.

Generally speaking, instanceof checking is relatively cheap. In JVM HotSpot, it comes down to numerically checking the type identifier in the object header.

This classic article describes why you should "write dumb code."

There is also a 2002 article that describes how to optimize instanceof in the JVM HotSpot .

+6
source

Once the JVM has warmed up, most operations can be counted in nanoseconds (millionths of a millisecond). Speaking of something expensive, you usually have to talk about your high cost regarding the alternative. Its almost impossible to describe something expensive in all cases.

Usually the most important is your time (and other developers on your team). Using instanceof can be expensive to develop and maintain code time, as it often indicates poor design. Using proper OOP methods is usually the best idea. 10 nano-second a instanceof can take, usually relatively trivial.

+3
source

The cost of specific operations performed inside the CPU almost never depends on performance. If performance is poor, it is almost always due to IO (network, disk) or inefficient code. Writing efficient code is much more likely to find a way to reduce the total amount of operations, rather than avoiding “expensive” operations (with the exception of those that are an order of magnitude more expensive, such as IO).

+1
source

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


All Articles