From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29241 invoked by alias); 10 Nov 2011 10:10:20 -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: 16569 Received: (qmail 12056 invoked from network); 10 Nov 2011 10:10:18 -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: <111110021007.ZM6786@torch.brasslantern.com> Date: Thu, 10 Nov 2011 02:10:07 -0800 In-reply-to: <20111110071946.GA2380@devbox> Comments: In reply to Eugene Dzhurinsky "Re: delay in exitting from zsh shell" (Nov 10, 9:19am) References: <20111109222020.GB10120@devbox> <111109195118.ZM6411@torch.brasslantern.com> <20111110071946.GA2380@devbox> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: delay in exitting from zsh shell MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Nov 10, 9:19am, Eugene Dzhurinsky wrote: } } Okay, I wrote stupid and simple program to de-duplicate lines in } history file: You can't compare that to what zsh is doing. The history file isn't just duplicate lines, it's duplicate shell parser constructs which may span multiple lines. The only way to _correctly_ deduplicate it is to run it through the parser while loading it; that's where all the time/CPU is going. } Am I missing something there if would say that history saving and } de-duplication is suboptimal? If a special routine that does nothing but deduplicate the file were to be added, it could probably be faster, yes. The history mechanism performs the deduplication by loading the file back in roughly as if all the commands were being typed at the command line again, so that the behavior of deduplication exactly reproduces what the shell would have done interactively with all the setopts that are in effect. This is simply not an operation that's done often enough -- nor is having 10000+ lines of shared deduplicated history a common enough user configuration -- for anyone to have undertaken to create an efficient deduplication routine that nevertheless faithfully reproduces the behavior of re-parsing the file. Feel free to contribute that ... However, it might be simpler just to unset the options that cause the file to be deduped on shell exit, and e.g. allow it to be deduped on shell startup instead.