From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16370 invoked by alias); 7 Apr 2012 16:43:32 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 16995 Received: (qmail 7568 invoked from network); 7 Apr 2012 16:43:30 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <120407094305.ZM20365@torch.brasslantern.com> Date: Sat, 07 Apr 2012 09:43:05 -0700 In-reply-to: <20120406183022.GA11651@mugenguild.com> Comments: In reply to Valodim Skywalker "Re: Large LS_COLORS makes auto_cd very slow" (Apr 6, 8:30pm) References: <120404005237.ZM10249@torch.brasslantern.com> <20120406183022.GA11651@mugenguild.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: Large LS_COLORS makes auto_cd very slow MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Apr 6, 8:30pm, Valodim Skywalker wrote: } } > For each of these categories, _setup line 12 rebuilds the value of } > the _comp_colors array to add new patterns such that any pattern that } > started with '=' gets copied with a prefix matching the tag currently } > being tested; e.g. '(commands)=...' or '(jobs)=...' } > } > This is done even for tags that won't have any matches because the } > colors array has to be ready for the internals to use when a match is } > found, there's no way to "call back" to build it on demand. } } Are these steps all hard requirements? I don't have a good overview of } things, but some of these parts seem like they could be rethought to } work faster or the cpu/memory tradeoff shifted a bit towards more memory } use or something. Does the array really need to be unique? Using the hash seive for arrayuniq seems to resolve that part of the problem. The array doesn't have to be unique, but making it not so will only make the other part of the problem [getcoldef()] worse. } How much fluctuation is in these contexts, this is a frequent } operation so maybe caching the entries, possibly only for known often } called contexts, could help? It's conceivable that getcoldef() could use a cache. The parse of each string passed to getcoldef() is not dependent on context, although the strings themselves are, so getcoldef() could just stash away every one it ever sees and return it the next time the same parse is needed. All the heap allocations [zhalloc()] in getcoldef() would have to become global allocations [zcalloc()], patcompile() would need to be called with the PAT_ZDUP flag, and the module boot_() and cleanup_() routines would then allocate and delete a hash table for the cache. However, this would only help on second and subsequent completions in a context that had been completed before. E.g., the first completion after "/b" in command position would still have a noticable delay; it checks at least eight different contexts.