Shulou(Shulou.com)06/02 Report--

This article mainly introduces JDBC and Hibernate how to read performance, the article introduces in great detail, has a certain reference value, interested friends must read it!

1. JDBC is still the fastest access method, whether it is Create or Read operation, it is JDBC fast.

2. Hibernate uses uuid.hex to construct primary keys, resulting in a slight performance loss, but not much.

3. Create operation, JDBC is faster than Hibernate in batch mode, and using batch mode consumes much more JVM memory than no batch mode.

4, read data, Hibernate Iterator speed is very slow, because he is every time next to get data from the database, this point from the observation task manager of the java process memory changes can also be seen very clearly, memory is dozens of K dozens of K increase.

5, read data, Hibernate List is very fast, because he is to take up the data at one time, this point from the observation task manager's java process memory changes can also be seen very clearly, memory is almost 10m of 10m increase.

6. JDBC reads data in the same way as Hibernate's List (this has a lot to do with JDBC drivers. Different JDBC drivers will result in different results), which can be judged by observing the memory changes of java processes. Since JDBC does not need to construct a bunch of Cat object instances like Hibernate, it takes up about half of JVM memory than Hibernate's List method.

7. Hibernate Iterator is not useless, it is suitable for selecting a small amount of data from a large result set, that is, it does not need to take up a lot of memory and can get the results quickly. In addition, Iterator is suitable for using JCS buffering.

Final conclusion:

Due to the major defects of MySQL's JDBC driver, the test results become meaningless and do not have any reference value, but we can roughly judge some conclusions:

◆ 's well-written JDBC is the fastest in any case.

◆ Hibernate List and Iterator are applicable in different situations, and there is no question of which is better or worse.

I personally think that Hibernate Iterator is the encapsulation of JDBC Result and Hibernate List is the encapsulation of Scrollable Result, so I speculate that if you do the same Read test on Oracle or DB2, there should be no difference in speed if the result set is smaller than FetchSize,4; if the result set is larger than FetchSize, but not many times that of FetchSize, the speed ranking should be:

JDBC Scrollable Result (time consuming least) < Hibernate List < JDBC Result < Hibernate Iterator

If the result set is very large, but only part of the record in the result set is taken, then the speed ranking:

JDBC Result < Hibernate Iterator < JDBC Scrollable Result < Hibernate List to avoid misleading, I * emphasize my conclusion:

1. A "carefully written" JDBC must be of high performance.

In fact, regardless of CMP,Hibernate,JDO and so on, all ORM is a package of JDBC, CMP is a heavyweight package, JDO is a medium package, and Hibernate is a lightweight package. In theory, ORM can never perform better than JDBC. Just like any high-level language will never run better than assembly language.

For Create and Update operations, because the average Java programmer may not necessarily use the Batch capabilities of JDBC, Hibernate will perform faster than JDBC.

For Read operations, ORM generally has double-layer buffering, that is, PrepreadStatement buffering and ResultSet buffering, while JDBC itself has no buffering mechanism. When using connection pooling, some connection pooling will provide PrepreadStatement buffering, and some even provide ResultSet buffering, but in general, Java programmers generally do not consider optimizing buffering when writing JDBC, and it is not realistic to do so, so in some cases ORM will appear to exceed the Read speed of JDBC.

2. Comparison between Hibernate List and Iterator.

This is what I want to focus on in the test, but because of the JDBC driver problem, the results become very unreliable, but some useful conclusions can still be drawn.

The Read operation consists of two steps: the * * step is to extract the data from the database, construct the result set, and put the data into the result set; the second step is to traverse the result set and get each row of data.

The List method fetches all the data into memory at one time to construct a very large result set. The main time cost is this step, which far exceeds the time cost of constructing the result set in JDBC and Iterator mode, and the memory cost is also very amazing. The speed of traversing the result set is amazing (from the above test results, 300000 of the recorded memory traversal is less than 100ms, because this step is not affected by JDBC, so the result is credible). Therefore, the List method is suitable for repeated operations on the result set, such as paging display, traversing back and forth, skipping to * lines, skipping to * lines, and so on.

The Iterator method only fetches the record id into memory, and does not take all the data into memory, so the time cost of constructing the result set is very small, which is less than that of JDBC and List, and the memory overhead is much lower. When traversing the result set, Iterator still accesses the database, and all the major time overhead is spent here. Therefore, Iterator is suitable for traversing the result set only once, and Iterator is especially suitable for fetching a small amount of data from a very large result set, in which case Iterator performance is very good. In addition, Iterator mode can make use of JCS buffering. In the case of using buffering, the traversal operation speed of Iterator mode will not be affected by the database access speed and will be thoroughly improved.

Hibernate Iterator JCS mode should be the fastest, Hibernate List speed and JDBC are relatively close, while Hibernate Iterator speed is still ridiculously slow. In addition, JDBC and List are greatly affected by Fetch Size. When Fetch Size is greater than 50, the speed increases significantly, while the speed of Hibernate Iterator does not seem to be affected by Fetch Size.

These are all the contents of the article "how JDBC and Hibernate read performance". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.