ipfs pin ls <not-pinned-hash> takes very long and uses lots of CPU

[hsanjuan]

Version information: 0.4.7-rc1

Type: Bug

Priority: P3

Description:

While ipfs pin ls <pinned hash> works fast. ipfs pin ls <unpinned hash> takes forever to inform the user that the hash is not pinned. I also observe around 5 secs 200% CPU usage until the request comes back. Tested with 0.4.5 and happens at least since then.

[hsanjuan]

I'll dig this up

[Kubuxu]

If you have 5s there, you can capture CPU profile and it will give you some data.

[whyrusleeping]

@hsanjuan its probably enumerating the entire pinset and making sure that the hash youre giving it isnt anywhere in any of the indirect pins

[hsanjuan]

@whyrusleeping ipfs pin ls takes shorter. Isn't that enumerating the whole pin set too? (btw, my pinset is rather small)

[whyrusleeping]

@hsanjuan If youre listing on a recursive or direct pin, it will see that its in the immediate pinset and short circuit. When its not in the top level set, it has to check whether or not its referenced indirectly. You might try just checking if your pin is --type=recursive

[hsanjuan]

The problem is that when checking if a single pin exists, the code takes every recursive pin and does a hasChild(cid), where hasChild calls recursively on the links from every child.

This means that branches will be recursively explored over and over even when they are shared by different parents. On the other side ipfs pin ls is faster because when doing pinLsAll(), previously visited branches are pruned in EnumerateChildren() because the cid is already part of the visited set.

I think it would make sense have the same approach as enumerateChildren() and prune already visited branches when searching if a pin exists.