richardstartin commented on PR #8764: URL: https://github.com/apache/pinot/pull/8764#issuecomment-1136099841
> So besides the single docId based scan evaluation which is improved in this and the previous PR #8759, one other thing that was showing up in the profile in #8634 was the `vtable stub` potentially hinting at overhead associated with virtual call dispatch over 32 concrete types of `FixedBitIntReader` inside `FixedBitSVForwardIndexReaderV2`. > > I am guessing that this overhead will also get amortized because of the bulk access being done from `next() -> matchValues -> applySV -> readDictIds -> applySV` and therefore reducing the number of times the virtual dispatch is done ? Yes, it's important to understand Hotspot inlining limitations (for anyone who isn't aware) 1. Three or more implementations (polymorphic call site) will never get inlined, but the offset into the vtable may get cached to speed up the dispatch, but any inlining dependent optimisations (scalarisation, counted loop optimisations) won't happen 2. Two or more implementations (biomorphic call site) may get inlined with a type condition, subject to other conditions (bytecode size, inlining depth, inlined stub size) 1. One implementation (monomorphic call site) will get inlined, subject to the same conditions, lots of implementations follow from this Vectorisation ameliorates all of this and amortises function call overheads, costs of missed optimisations, creates larger scopes for Hotspot to optimise within the method which processes the batch. It's probably worth making more disruptive changes to push vectorisation all the way up to the top given that the code is JIT compiled. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
