Re: Performance of _store_cache and _retrieve_cache

[Bart Schaefer <schaefer@brasslantern.com>]

On Feb 8,  5:19pm, Daniel Hahler wrote:
} Subject: Performance of _store_cache and _retrieve_cache
} 
} I've noticed that the completion systems cache mechanism
} (_retrieve_cache and _store_cache) is slow with large lists (~50000).

[...]

} The problem is that `source ./pip_allpkgs.slow` takes about 8 seconds,
} and is slower than generating the list anew!

This might be addressed by having a policy check at _store_cache time as
well as at _retrieve_cache.  (Check a different policy, that is.)

I've been wondering whether the cache mechanism should use zstyle
rather than the parameter space.  Unfortunately the current interface
encourages this type of thing:

  if ( [[ ${+_zypp_all_raw} -eq 0 ]] || _cache_invalid ZYPPER_ALL_RAW ) &&
     ! _retrieve_cache ZYPPER_ALL_RAW;
  then

or

  if [[ -n $state ]] && (( ! $+_svn_cmds )); then
    typeset -gHA _svn_cmds
    if _cache_invalid svn-cmds || ! _retrieve_cache svn-cmds; then

I.e., the caller is aware that the cache is stored in a variable and
therefore explicitly tests the variable as well as _cache_invalid.
That makes it a little difficult to change the backend.

Further the _cache_invalid tests there are actually redundant, it'll be
called again by _retrieve_cache.  So there's a bunch of cleanup to be
done in the use cases before the backend could be altered.

-- 
Barton E. Schaefer