-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimisations for LoadNextMsgMulti
#6448
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general LGTM, but when we hit a dmap entry, before we would update load ts. So maybe we should set a boolean when we match dmap and on exit update that just once?
46d73c5
to
2a93e6c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This avoids a potentially expensive linear walk if it is obvious that the block FSS contains less subjects than sequences that we would otherwise have to scan. Signed-off-by: Neil Twigg <[email protected]>
…alls Signed-off-by: Neil Twigg <[email protected]>
2a93e6c
to
5499017
Compare
This updates `generatePerSubjectInfo`, `NumPending` and `NumPendingMulti` to avoid updating the last load timestamp in a tight-loop while skipping over a potentially large number of interior deletes, as this becomes noticeable in the CPU profile. Similar to one of the changes in #6448. Signed-off-by: Neil Twigg <[email protected]>
This PR optimises
LoadNextMsgMulti
by doing two things:firstMatchingMulti
by using subject tree intersection when it looks like the FSS size is smaller than the scan range, this should be less expensive (although the threshold for choosing strategy may need further attention);dmap
before callingmb.cacheLookup()
in either the FSS search or the linear scan, such that we can avoid callingtime.Now()
a lot when we are tight-looped scanning over a large number of interior deletes.This PR provides a 2x improvement on the 1000-filter
LoadNextMsgMulti
unit test and provides a 10x improvement when tested against a store that has extremely sparse messages and 8 consumer filters.Signed-off-by: Neil Twigg [email protected]