You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here is a trace I captured from loading dist.ipfs.io's favicon (on v0.8.0-rc2):
You can see that it loads the same ressource over and over, there is no point to restarting from /ipns/dist.ipfs.io all the time.
Ideally once we resolve a path component we followup all future resolution from this path component or better.
They all endup calling into namesys.
It doesn't look like the latency impact is very bad because all but the first call to ResolvePath and first call to BlockAPI.Get are very fast, so they are probably hitting a cache, it looks like a low hanging fruit that would reduce allocations and CPU usage a bit tho.
The text was updated successfully, but these errors were encountered:
@Jorropo I think this has been solved in the meanwhile through the successive refactors. It seems like we only hit Namesys once now. I tried with a few different pages and only see a single call.
Here is a trace I captured from loading
dist.ipfs.io
's favicon (onv0.8.0-rc2
):You can see that it loads the same ressource over and over, there is no point to restarting from
/ipns/dist.ipfs.io
all the time.Ideally once we resolve a path component we followup all future resolution from this path component or better.
They all endup calling into
namesys
.It doesn't look like the latency impact is very bad because all but the first call to ResolvePath and first call to
BlockAPI.Get
are very fast, so they are probably hitting a cache, it looks like a low hanging fruit that would reduce allocations and CPU usage a bit tho.The text was updated successfully, but these errors were encountered: