Closed
Description
Something to be aware of: the more Pins user has, the slower pin.ls
is.
I have around 1k of pins and it takes 10 seconds to do pin check against all pinned blocks via URL executed by my browser:
$ time curl -X POST 'http://127.0.0.1:5001/api/v0/pin/ls?paths=bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi&stream=true&arg=bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi'
{"Message":"path 'bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi' is not pinned","Code":0,"Type":"error"}
curl -X POST 0.00s user 0.00s system 0% cpu 10.774 total
This is result of inefficiencies in go-ipfs 0.6 (pinstore needs revamp, I use flatfs on slow spinning disk) but illustrates that if we block UI on pin status check, it may take 10 seconds or more.
I suggest we are cognizant of this possibility and audit our UI, decouppling "realtime" elements (breadcrumbs context menu – #1599) from pin ls
for snappier interface.
For example, when pinning service integration lands (ipfs/ipfs-gui#91), we could have static action in context menus to open "pin status modal" and fetch pin status (local+remote) only there.
Metadata
Metadata
Assignees
Labels
Medium: Good to have, but can wait until someone steps upEstimated to take multiple days, but less than a weekPrior experience is likely helpfulA bug in existing code (including security flaws)Work required to avoid breaking changes or harm to project's status quoNeeds further analysis before proceedingNeeds input from the current maintainer(s)