Replies: 1 comment 5 replies
-
|
First, I don't think anyone on the team would consider 1700 a normal amount of images. That is certainly well outside of the range anyone would test with. We don't really have performance benchmarks, at least not in that size range. I have not looked at the code but it is certainly possible that there might be some O(n^2) or worse O(2^n) performance here which could explain a big increase in command time. Without a reproducer and storage configuration there is likely not much we could tell here regardless. |
Beta Was this translation helpful? Give feedback.
5 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hey, I had image list | wc returning 1700 which seems low/normal for me - and it took about 30s to complete - -a took a bit longer about 35s
I did a podman image prune and have 500 images now and image list is 0.5s
I saved the hash list from the prune and it was 2034
My internal explanation for the difference in numbers is that 2034 is layers deleted and 1700 was top level leaf layers which in many cases shared layers beneath. That's reasonable if true.
But why did the prune speed it up so much - why was it SO slow just listing what's there? Why is it acceptably fast now when there's still 500 there?
Wound up here in discussion instead of on an issue. Hopefully not radio silence :-)
I will wind up with hundreds more images over the coming weeks/months so I'll probably run into it again if diagnostics are useful in terms of improving things. Something somewhere seems to be wrong/doing unneeded work or something.
Beta Was this translation helpful? Give feedback.
All reactions