Skip to content

Breadcrumb context menu slow to appear when user has many local pins #1618

Closed
@lidel

Description

@lidel

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

No one assigned

    Labels

    P2Medium: Good to have, but can wait until someone steps upeffort/daysEstimated to take multiple days, but less than a weekexp/intermediatePrior experience is likely helpfulkind/bugA bug in existing code (including security flaws)kind/maintenanceWork required to avoid breaking changes or harm to project's status quoneed/analysisNeeds further analysis before proceedingneed/maintainers-inputNeeds input from the current maintainer(s)

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions