mysql/mysql-js

Deoptimizations in NDB SPI

jdduncan opened this issue · 2 comments

From node --trace_deopt jscrund --adapter=ndb --spi we see a list of deoptimizations in NDB SPI code:

For Indy:

  • DBOperation
  • DBTableHandler.getFields
  • DBTableHandler.getMappedFieldCount
  • execute
  • stats_incr
  • DBTableHandler.getColumnMetadata
  • DBOperation.prepare
  • allocateRowBuffer
  • completeExecutedOps
  • releaseKeyBuffer

For Each:

  • NdbSession.getTransactionHandler
  • NdbSession.buildInsertOperation
  • proto.execute
  • encodeRowBuffer
  • DBTableHandler.get
  • onExecute
  • getExecIdForOperationList
  • run
  • attachErrorToTransaction
  • exports.closeActiveTransaction
  • begin

For bulk:

  • QueuedAsyncCall.enqueue

DBOperation: In persist(), we call DBOperation with valid tableHandler and null indexHandler. Then we come to find(), where we have a valid indexHandler and null tableHandler. This triggers the deopt. But after this DBOperation() is not deoptimized again.

getFields(): called from NdbOperation with a variety of signatures.

getMappedFieldCount(): deoptimized 3 times. One point is that "this" could be a DBTableHandler or a DBIndexHandler.

getColumnMetadata(): deoptimized 3 times. Again, "this" could be DBIndexHandler or DBTableHandler.