Closed Ramilito closed 1 month ago
Does every \--cached
is working for me, hitting \
Hmm I was hoping the cached would solve the performance tbh, running my own test seems to be performant, could you try running these commands?
time kubectl api-resources --cached
time kubectl api-resources
For me, the difference is almost 150ms so it seems to be doing something, the timing inside the plugin is also similar in loading time, from: Execution time: 0.086942375 seconds <- with cached Execution time: 0.176638708 seconds <- without cached
Hmm I was hoping the cached would solve the performance tbh, running my own test seems to be performant, could you try running these commands?
time kubectl api-resources --cached
time kubectl api-resources
For me, the difference is almost 150ms so it seems to be doing something, the timing inside the plugin is also similar in loading time, from: Execution time: 0.086942375 seconds <- with cached Execution time: 0.176638708 seconds <- without cached
i have a cluster with many CRDs, a heavy cluster. it gives me:
kubectl api-resources --cached 0.24s user 0.07s system 15% cpu 1.996 total
for me it's noticable for a window that should open very quick (maybe also rendering the float takes time)
I think it's better to keep an in-memory cache (M.cached_api_resources = {...}
)
Yeah two seconds is waaaaay too long for a quick nav, Il check if I can do a preload and a cache.
Added a new issue: #139
Solves #135 and parts of #23
Adds an alias search pop with tab autocomplete. Choosing one will load that view. If we have support for the view, that will be loaded otherwise a fallback view (generic view) with basic functionality (describe, edit, delete)