FWD » Core Development » Database

There is an overhead in using foreach loops: for (Object obj : objs). This is because an iterator object is generated in the background. This object is defined in the heap-memory, so the memory allocation and GC overhead affect performance. Consider replacing all for-each loops with classical for loops: for (int i = 0; i < objs.size(); i++) where possible (List or Java arrays). This should give us some modest, yet honest performance boost. Please address this right away!

Second, there is an overhead with using lambdas, especially the ones which reference local variables and arguments. Please report with a list of lambda from the FWD-H2 code and review their use one-by-one. If there are tens of lambda in the FWD-H2 code, we should change the strategy (maybe group them by use). Please address this as soon as possible

Lastly, I think there may be an overhead by using synchronized even in single-user H2 instances. Note that the default now is private temp-tables with LOCK-MODE 0: every single H2 instance is private to the user, so it is single-user. However, the H2 code is written for multi-user environments, so there are a lot of synchronized blocks (on session and database). Note that LOCK-MODE 0 just avoids doing the table logical locking using Java Locks. For this matter, consider adapting the FWD-H2 code to honor LOCK-MODE even for database and session synchronizing - maybe replace synchronized blocks with Java locks? Before doing that, please check that there are no daemon threads which analyze the H2 structure or something that really depends on having the session or database synchronized beyond the obvious multi-user environments. Please consider this with care, as we don't want to have concurrency regressions as they are hard to spot

Alexandru Lungu wrote:

Second, there is an overhead with using lambdas, especially the ones which reference local variables and arguments. Please report with a list of lambda from the FWD-H2 code and review their use one-by-one. If there are tens of lambda in the FWD-H2 code, we should change the strategy (maybe group them by use). Please address this as soon as possible

I've gone through the H2 code and I did not find any lambdas. I think this point can be considered done.

Created 7132a_h2 from trunk rev. 11. Committed rev. 12 including lots of replacements from for-each loops to classical for loops. I am planning to do a rev. 13 ASAP including other for-each loops rewritting and profile 7132a_h2.

Committed rev. 13 finishing replacements from for-each loops to classical for loops. I've done some tests, but there is no visible difference (in 3 test rounds: 1 shown +0.2%, 1 shown a +0.1%, 1 shown -0.1%). Unfortunately, this is not a consistent improvement. I will keep 7132a_h2 for reference for now. I will move on with the synchronization part.

Alexandru Lungu wrote:

Lastly, I think there may be an overhead by using synchronized even in single-user H2 instances. Note that the default now is private temp-tables with LOCK-MODE 0: every single H2 instance is private to the user, so it is single-user. However, the H2 code is written for multi-user environments, so there are a lot of synchronized blocks (on session and database). Note that LOCK-MODE 0 just avoids doing the table logical locking using Java Locks. For this matter, consider adapting the FWD-H2 code to honor LOCK-MODE even for database and session synchronizing - maybe replace synchronized blocks with Java locks? Before doing that, please check that there are no daemon threads which analyze the H2 structure or something that really depends on having the session or database synchronized beyond the obvious multi-user environments. Please consider this with care, as we don't want to have concurrency regressions as they are hard to spot

I've committed some changes to 7132a_h2, rev. 14. I've added some checks to potentially remove the synchronized keyword for some blocks. Mainly, if LOCK_MODE is set to 0, then synchronized should not be needed.

I've tested these changes with ./build.sh testFWD and a large customer application and got no errors.

Also, as a side note, I did not manage to rewrite all the synchronized blocks in H2 since there are quite a lot. I've tried to focus on the more frequent ones.

Alexandru Lungu wrote:

Please make a new commit which reverts the changes for that less used classes. I would like to test such an intermediate solution and guarantee that we have a subset of changes which are stable enough. At that point we can do baby steps to integrate your other changes.

I've considered what you said and I reverted some of the changes. Also, I've dealt with those wildcard imports.
The new revision is on 7132a_h2, rev. 15.

Done several testing iterations with 7132a_h2/rev. 15 and the issue is solved. The bad news are that I couldn't notice any consistent performance improvement (<0.1%). In this state, 7132a_h2 is stable enough to be merged, but we may consider some further optimizations to make it worth it.