From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19428 invoked by alias); 27 Sep 2010 01:26:43 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 28305 Received: (qmail 29894 invoked from network); 27 Sep 2010 01:26:41 -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 autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at benizi.com designates 64.130.10.15 as permitted sender) Date: Sun, 26 Sep 2010 21:26:08 -0400 (EDT) From: "Benjamin R. Haskell" To: Bart Schaefer cc: zsh-workers@zsh.org Subject: Re: (bug report) Starting zsh takes ~5 seconds with the latest commits after 20th of September with big history file In-Reply-To: <100926131528.ZM407@torch.brasslantern.com> Message-ID: References: <20100926181231.GA4616@arch> <100926131528.ZM407@torch.brasslantern.com> User-Agent: Alpine 2.01 (LNX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Sun, 26 Sep 2010, Bart Schaefer wrote: > I was somewhat concerned that this was going to happen. This must be > because of zsh-workers/28295 (use lexer to split words from history). > > The logging-off part is actually of more concern, it's probably > because you are sharing history and/or have some of the > duplicate-suppression options set. > > Probably the right thing to do is: > > (1) have an option for the new behavior (HIST_LEX_WORDS ?); > > (2) implicitly turn that option off on the way through shell exit, so > history rewrites/comparisons use faster processing. > Not that confirmation was needed, but yes, that's the commit that did it: $ git tag workers-28295 5ca08ec # see git-build-zsh script below... $ git build-zsh workers-28295~1 $ time /tmp/zsh-git-workers-28295\~1/bin/zsh -i =(print -l exit) > /dev/null [...] 1.224 total $ git build-zsh workers-28295 $ time /tmp/zsh-git-workers-28295/bin/zsh -i =(print -l exit) > /dev/null [...] 5.108 total Personally, I don't think I'd ever turn on a HIST_LEX_WORDS option. (As mentioned in the other thread, I was just glad there was a simple explanation for the seemingly buggy behavior.) Starting to regret noticing the problem in the first place. :-\ On the other hand it might be yet-another kick in the pants I need to start hacking a DB-based history mechanism. [The first kick:] I like to keep my entire history (HISTSIZE=50000000, SAVEHIST=$HISTSIZE, setopt extended_history). But, occasionally I'll let my home dir partition fill up (usually from forgetting that I have a Wireshark instance up in the background, slowly chewing up disk space). After I clear out some space, the entire history file gets its timestamps reset to the current time. I check it in to git daily, but still, it's frustrating to lose any history. -- Best, Ben ==> git-build-zsh <== #!/bin/zsh die () { echo "\e[31m"$argv"\e[0m" ; exit 1 } (( $#argv )) || die "Usage: $0 revision" script=$0:t rev=$1 TRAPZERR () { die "Failed: $last_cmd" } TRAPDEBUG () { last_cmd=$ZSH_DEBUG_CMD print -n "\e]2;$last_cmd - $script $rev\a" } git co $rev autoreconf ./configure --prefix=/tmp/zsh-git-$rev --enable-multibyte make -j5 make install