Project

General

Profile

Feature #7447

Compare ValueString and ValueStringIgnoreCase faster in FWD-H2

Added by Alexandru Lungu 11 months ago. Updated 9 months ago.

Status:
Closed
Priority:
Normal
Target version:
-
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
version:

Related issues

Related to Database - Feature #7363: Improve H2 Value caching, hashing and equals Test

History

#1 Updated by Alexandru Lungu 11 months ago

  • Tracker changed from Bug to Feature

There are several hits of Value.compareTo, where the operands are ValueString and ValueStringIgnoreCase. This is mainly because JDBC doesn't allow setStringIgnoreCase, so FWD-H2 is forced to "cast" the string parameters to ValueStringIgnoreCase each time they are used (usually on index look-up) against an ignore-case column.

Value.convertTo from a ValueString to ValueStringIgnoreCase implies the construction of a ValueStringIgnoreCase:
  • cache look-up for String and Value;
  • in case of cache miss, a ValueStringIgnoreCase is built
  • the hash of the string is computed

All this work is done, so that ValueStringIgnoreCase.compareTypeSafe can do mode.compareString(value, ((ValueStringIgnoreCase) o).value, true). Having mode.compareString(value, ((ValueString) o).value, true) would produce the same result - they have the same underlying String.

I suggest the following solution:
  • If Value.convertTo has forComparison flag set on true, the ValueString will not convert to ValueStringIgnoreCase, but stay in place. The same goes for ValueStringIgnoreCase into ValueString
  • ValueString.compareTypeSafe and ValueStringIgnoreCase.compareTypeSafe will be sensitive to the other data type. Because, ignore-case has higher order, if any of the operands is ignore-case, the comparison will be ignore-case.

This change will optimize the number of Value instances created, cache look-up + override, string equals and caches.

#2 Updated by Alexandru Lungu 11 months ago

  • Related to Feature #7363: Improve H2 Value caching, hashing and equals added

#3 Updated by Alexandru Lungu 11 months ago

  • Assignee set to Dănuț Filimon
  • Status changed from New to WIP

Danut, please check if this is still happening after your changes in #7454. Of course, before the changes, there were a lot of such comparisons. I don't know if this task is revevant after the changes there. Please check if there are still comparisons between ValueString and ValueStringIgnoreCase.

#4 Updated by Dănuț Filimon 9 months ago

Alexandru Lungu wrote:

Danut, please check if this is still happening after your changes in #7454. Of course, before the changes, there were a lot of such comparisons. I don't know if this task is revevant after the changes there. Please check if there are still comparisons between ValueString and ValueStringIgnoreCase.

I retested using an available customer application and there were no comparisons between ValueString and ValueStringIgnoreCase. The testing is really slow when using a conditional breakpoint in Value.compareTo, so I did not browse the application too much (~30 min).

#5 Updated by Dănuț Filimon 9 months ago

Great news! I retested the customer application using a different approach which allowed me to test it a lot faster and found no comparisons between ValueString and ValueStringIgnoreCase.

#6 Updated by Alexandru Lungu 9 months ago

  • Status changed from WIP to Review
  • % Done changed from 0 to 100

Ok, this can be closed then - let me know if there is something left here to discuss

#7 Updated by Greg Shah 9 months ago

  • Status changed from Review to Closed

Also available in: Atom PDF