From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 327 invoked by alias); 14 Aug 2011 18:06:31 -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: 16219 Received: (qmail 4671 invoked from network); 14 Aug 2011 18:06:20 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) 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.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <110814110602.ZM14155@torch.brasslantern.com> Date: Sun, 14 Aug 2011 11:06:02 -0700 In-reply-to: <20110814145749.GA6341@andrew.cmu.edu> Comments: In reply to gi1242+zsh@gmail.com ""Once-a-day" long delay before startup" (Aug 14, 10:57am) References: <20110814145749.GA6341@andrew.cmu.edu> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: "Once-a-day" long delay before startup MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Aug 14, 10:57am, gi1242+zsh@gmail.com wrote: } } I notice that about every so often (at least once a day) when I open a } new shell, my hard disk spins for 15 secs or so before zsh starts. Per Vincent's remarks, you should determine whether the delay comes before zsh even begins reading its startup files, or sometime during. } Would anyone know what the problem is? I'm guessing it's from } reading/recreating the completion cache. If by "the completion cache" you mean the ~/.zcompdump file, I'd say that's unlikely to be related. However, it could have to do with building the command hash table (scanning the directories in $path), particularly if you have run some sort of memory-intensive operation that may have caused the kernel to flush out part of its filesystem cache. There are various setopts to encourage that scan to be done incrementally, but if your startup files include external commands that are found in directories toward the end of the search path, all the preceding directories are likely to get scanned anyway. You might try placing unsetopt hashcmds hashdirs hashlistall at the beginning of ~/.zshenv and make sure you don't set any of those nor correct and correctall until as late as possible in ~/.zshrc. This will help assure that the hash table is not rebuilt during startup file processing (unless of course you're explicitly "rehash"ing somewhere) and is never built during non-interactive scripts. Of course if /etc/zshenv is doing something intensive that's not going to help. The hashlistall option mostly applies to compctl, not compsys, so you can probably leave it unset.