From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8403 invoked by alias); 4 Apr 2012 07:53:10 -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: 16981 Received: (qmail 7320 invoked from network); 4 Apr 2012 07:53:08 -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: <120404005237.ZM10249@torch.brasslantern.com> Date: Wed, 04 Apr 2012 00:52:36 -0700 In-reply-to: =?iso-8859-1?Q?=3CCABZhJg-xieMZAOEmbYzSb5T-3O8aLNurvPk=3DSiXs?= =?iso-8859-1?Q?PGjTpAMg-Q=40mail=2Egmail=2Ecom=3E?= =?iso-8859-1?Q?Comments=3A_In_reply_to_Jesper_Nyg=E5rds_=3Cjesper=2Enygar?= =?iso-8859-1?Q?ds=40gmail=2Ecom=3E?= =?iso-8859-1?Q?________=22Large_LS_COLORS_makes_auto_cd_very_slow=22_=28A?= =?iso-8859-1?Q?pr__3=2C__9=3A08pm=29?= References: 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=iso-8859-1 Content-transfer-encoding: quoted-printable On Apr 3, 9:08pm, Jesper Nyg=E5rds wrote: } } /us }=20 } whereas completion after an explicit cd is nearly instantaneous: }=20 } cd /us }=20 } It seems rather odd to me that coloring would render this so slow. I } suppose the delay is caused by zsh trying to color some list of } possible completions, but why would it be so very slow? /us as the first word in the buffer is in command position, so is completing any/all of commands, executables, builtins, functions, aliases, suffix-aliases, reserved-words, jobs and parameters. 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 '=3D' gets copied with a prefix matching the tag currently being tested; e.g. '(commands)=3D...' or '(jobs)=3D...' 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. The expensive bit is that _comp_colors is declared as a unique array, so every time it gets rebuilt the resulting 1700+ entries are all compared against one another to make sure there is no duplication. Repeat that nine times and it takes a while. With "cd" in front, it's restricted to directories only, so the array is only rebuilt once. Addenda for -workers: Anybody want to have a stab at creating a vastly more efficient version of Src/params.c:arrayuniq() ? I came up with a faster way to remove the duplicate elements, but the problem here is to efficiently determine that there are no duplicates to remove. Perhaps throw the elements into a hash table and then make one pass looking up each element.