Deoptimizations in NDB SPI
jdduncan opened this issue · 2 comments
jdduncan commented
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
jdduncan commented
jdduncan commented
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.