FWD » Core Development » Database

• 26.8k caused by DMO setters (Handler.invoke)
• 19.6k cause by Validation.validateMaybeFlush
  • 5.5k from RB.endBatch
  • 14k from Handler.invoke
  • 2 from RB.flush

• 207k calls to BitSet.get (336ms)
• 254k calls to BitSet.getNextBit (413ms)
• 9 calls to BigDecimal.equals (<0.1ms)

• 207k HashMap instances being created
• ~254k Object[] instance being created and put in the maps.

All times are affected by YK overhead.

• In most cases of Validation.validateMaybeFlush, the output of getActiveUpdateDiffs is not used!
• When it is required, it is used to report change. However, that cases only report the change that took place on one single index affected by the setter. Thus, there is no need to actually store all changes in a map.

• I suppose we can pass down the ormIndex and extentIndex we are interested of to getActiveUpdateDiffs.
• Is there any point in using getActiveUpdateDiffs inside validateMaybeFlush and return it instead of computing them up-front, before the call to validateMaybeFlush? I suppose not, so:
  • compute getActiveUpdateDiffs before
  • refactor validateMaybeFlush to return true/false (to replace whether it was supposed to return active diffs or not).
  • if it returned false, then ignore the output of getActiveUpdateDiffs

I think we can rename getActiveUpdateDiffs to getActiveUpdateDiff as it will gain one diff based on propIndex and extent.

I committed the code to 9667a/15716, it is ready for review.

• From BaseRecord.getActiveUpdateDiffs
  

  if(dirtyProps.get(actualIndex) || !Objects.equals(activePropPreviousValues[actualIndex], 
  +                                                        data[actualIndex]))
  

• it should be && instead of ||
• also mind the needed space after if keyword

I committed the changes to rev 15717.

• validation.validateMaybeFlush(); is indented 4 spaces instead of 3. Same applies to diff = null; following if (!validateMaybeFlush(currentRecord, false, false))
• The offsets of the properties are the keys. comment is redundant for addUnreportedChanges
• please also move the
  

  // NOTE: if the property was denormalized, the property index [ormIndex] already contains
                     //       the extent index

  • comment with extentIndex.

• changing extent fields of temporary tables (using normalized extent tables): double-check the diff is generated right, for the correct index.
• changing extent fields of persistent tables (using denormalized extent fields): double-check the diff is generated right, for the correct index.
• batch assign, buffer-copy, buffer-copy with assign (with temp and persistent)

• 2 large customer application unit tests and ChUI regression tests.

Please merge 9667a to trunk after 9615a.