Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: (bug report) Starting zsh takes ~5 seconds with the latest commits after 20th of September with big history file
- X-seq: zsh-workers 28305
- From: "Benjamin R. Haskell" <zsh@xxxxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- Subject: Re: (bug report) Starting zsh takes ~5 seconds with the latest commits after 20th of September with big history file
- Date: Sun, 26 Sep 2010 21:26:08 -0400 (EDT)
- Cc: zsh-workers@xxxxxxx
- In-reply-to: <100926131528.ZM407@xxxxxxxxxxxxxxxxxxxxxx>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <20100926181231.GA4616@arch> <100926131528.ZM407@xxxxxxxxxxxxxxxxxxxxxx>
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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author