-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
always try to read ahead by at least 5 blocks in the PBDagReader #5162
Changes from 4 commits
12719a7
0344e3e
ff3efb5
5c0dc6a
7fd3404
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -68,16 +68,13 @@ func NewPBFileReader(ctx context.Context, n *mdag.ProtoNode, pb *ftpb.Data, serv | |
|
||
const preloadSize = 10 | ||
|
||
func (dr *PBDagReader) preloadNextNodes(ctx context.Context) { | ||
beg := dr.linkPosition | ||
func (dr *PBDagReader) preload(ctx context.Context, beg int) { | ||
end := beg + preloadSize | ||
if end >= len(dr.links) { | ||
end = len(dr.links) | ||
} | ||
|
||
for i, p := range ipld.GetNodes(ctx, dr.serv, dr.links[beg:end]) { | ||
dr.promises[beg+i] = p | ||
} | ||
copy(dr.promises[beg:], ipld.GetNodes(ctx, dr.serv, dr.links[beg:end])) | ||
} | ||
|
||
// precalcNextBuf follows the next link in line and loads it from the | ||
|
@@ -92,15 +89,37 @@ func (dr *PBDagReader) precalcNextBuf(ctx context.Context) error { | |
return io.EOF | ||
} | ||
|
||
if dr.promises[dr.linkPosition] == nil { | ||
dr.preloadNextNodes(ctx) | ||
// If we drop to <= preloadSize/2 preloading nodes, preload the next 10. | ||
for i := dr.linkPosition; i < dr.linkPosition+preloadSize/2 && i < len(dr.promises); i++ { | ||
// TODO: check if canceled. | ||
if dr.promises[i] == nil { | ||
dr.preload(ctx, i) | ||
break | ||
} | ||
} | ||
|
||
nxt, err := dr.promises[dr.linkPosition].Get(ctx) | ||
if err != nil { | ||
dr.promises[dr.linkPosition] = nil | ||
switch err { | ||
case nil: | ||
case context.DeadlineExceeded, context.Canceled: | ||
err = ctx.Err() | ||
if err != nil { | ||
return ctx.Err() | ||
} | ||
// In this case, the context used to *preload* the node has been canceled. | ||
// We need to retry the load with our context and we might as | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could we elaborate a bit more on this? I had the impression we're always using the same There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We're using the context from the call Read call. IMO, that's the correct context as it allows us to cancel reads and seek elsewhere (canceling any associated preloading as well). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry, scratch that. If the user is using There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
It seems to me there are only (or mainly) two possibilities. The most common (by far I think) is that the reader's context is used everywhere, so in fact there is only one context (and this part of the code isn't executed). The second, and less common,
which is when this scenario takes place (if I understand correctly). Clarifying that distinction seems worth it, IMO. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fair enough. |
||
// well preload some extra nodes while we're at it. | ||
dr.preload(ctx, dr.linkPosition) | ||
nxt, err = dr.promises[dr.linkPosition].Get(ctx) | ||
dr.promises[dr.linkPosition] = nil | ||
if err != nil { | ||
return err | ||
} | ||
default: | ||
return err | ||
} | ||
dr.promises[dr.linkPosition] = nil | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Always remove the promise. There's no reason to leave this around. |
||
|
||
dr.linkPosition++ | ||
|
||
switch nxt := nxt.(type) { | ||
|
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.
(Apologies in advanced for the noise if I'm misunderstanding what this code does.)
So, if I'm understanding this correctly, right now the number of preloaded nodes available in advance goes like 10, 9, 8, ..., 0, all of a sudden the algorithm realizes it's out of nodes and has to load 10 more, causing the stuttering.
In that case, could we just move the
for
logic insidepreload
, calling it here every time without checking ifpromises[dr.linkPosition]
isnil
, so as to say: "I've consumed one node, heypreload()
, make sure I still havepreloadSize
nodes available in front of me, you figure out what to do".Maybe
preload
wouldn't even need thefor
, in the first call,dr.promises[0] == nil
, loadpreloadSize
nodes altogether, and after that, every time it's called (because a node has been consumed), preload the nodedr.promises[dr.linkPosition + preloadSize]
(assuming here that every node beforedr.linkPosition + preloadSize
is already loaded).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.
I've just realized that all the time I was talking about nodes I should have been talking about node promises, I can't know if there's a node until I call
Get()
right?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.
Sounds reasonable.
Technically, you can seek around so I'd rather be robust (the check is cheap).
No, but you can know if we've made a request for the node (i.e., the promise exists).
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.
Actually, it looks like making that change makes the other call to preload trickier. That second call currently overwrites any existing promises assuming that if the first preload has been canceled, the later ones probably have been as well.
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.
Note that fetching multiple blocks at once is more efficient.
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.
Oh, so maybe another constant N should be added that would indicate to call preload only if there are less than N available promises, to avoid calling it every time a node is consumed, e.g., if N is 5 then the number of available promises in advance would go like 10, 9, ..., 5, only now call preload, 15, 14, ..., 5, call preload again, etc.
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.
Maybe
preload()
could be extended to also check if the context ofdr.promises[i]
has been cancelled, not only that it'snil
. (Another argument could be added topreload()
to indicate if we want to overwrite the promises, but the other solution sound more correct to me.)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.
That's what I currently do. If we have fewer than half
preloadSize
loaded, I load the nextpreloadSize
. That means we vary between 5 and 15.That's what the TODO is about. However, that requires a change to the promises. See: ipfs/go-ipld-format#34
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.
I see, thanks for the clarification, then maybe we could add that extra argument to indicate that the current promises are cancelled and
preload
should request them again (overwriting the previous ones), if you think it's worth it.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.
I could but that doesn't seem any better to me. It just moves code from one place to another and then puts it behind a condition. Once we merge that linked PR, definitely.