From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4880 invoked by alias); 10 Nov 2011 07:20:06 -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: 16568 Received: (qmail 28833 invoked from network); 10 Nov 2011 07:19:55 -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=-0.8 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_WEB,T_DKIM_INVALID,T_TO_NO_BRKTS_FREEMAIL autolearn=no version=3.3.2 Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.google.com designates 209.85.161.43 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=7rQTsGKwKcVPrGQ3pxo+kPc8GMc8mGyh0y5IlYHQVs0=; b=jjx4lg+m4DPRjOeLGjzz11z3SDC5JeQF/MAauJctqcbOkRIulhem8vs+BmVAr7BB3A ttj1EIraH45+tHG50VbcXvuKQqcY/F390nr1LqOHtzobv+cybxdOBk1yNaG5LAm0dWTQ nuWKysA374qvvPYCAaDdt2eZt1LxHdUBA5PiM= Date: Thu, 10 Nov 2011 09:19:46 +0200 From: Eugene Dzhurinsky To: zsh-users@zsh.org Subject: Re: delay in exitting from zsh shell Message-ID: <20111110071946.GA2380@devbox> Mail-Followup-To: zsh-users@zsh.org References: <20111109222020.GB10120@devbox> <111109195118.ZM6411@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <111109195118.ZM6411@torch.brasslantern.com> User-Agent: Mutt/1.5.21 (2010-09-15) --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 09, 2011 at 07:51:18PM -0800, Bart Schaefer wrote: > This tends to imply that what's taking those 3-5 seconds is searching > your history file for duplicate entries in order to enforce the > hist_save_no_dups option. Also, inc_append_history may allow the file > to grow to up to 10500 lines for a SAVEHIST of 10000, and those extra > lines will be trimmed at shell exit. >=20 > In more detail, when you use inc_append_history and/or share_history > along with hist_save_no_dups, zsh re-reads and de-duplicates the entire > file from disk after it has obtained a lock for it, rather than just > dumping out the history that is already in memory, because it can't > know if some other shell has appended something new to the file before > the lock was obtained. The speed of the disk is inconsequential to the > CPU expended doing the deduplication. Okay, I wrote stupid and simple program to de-duplicate lines in history fi= le: import qualified Data.ByteString.Char8 as C8 import Data.List import System import Control.Monad fixHist =3D nub . C8.lines main =3D do (fname:_) <- getArgs hl <- liftM fixHist $ C8.readFile fname C8.writeFile fname $ C8.unlines hl function nub is O(n^2) time-complex, and still it takes less than second in order to read file, optimize it and write it down. > ./hst .histfile.tst 0.89s user 0.01s system 99% cpu 0.901 total and I believe that using linked hashtables will improve performance as well. Am I missing something there if would say that history saving and de-duplication is suboptimal? --=20 Eugene N Dzhurinsky --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBAgAGBQJOu3sRAAoJEJl2g18bZPdRplUH/2GP294cF4VC0/sCj9WWsqZ7 tkV9jcBzTVHhRyS113/OeSWlYhTVRuQCd8LF5wT3/W3BNZM/mPDMDVLQ3TwNWF+F MbqZaaIznF9IZya0vbjzRZ0te5XHpTuTUMs22VHsoGe7DfOKwUf0nrA6lmowVPPY Pekg7Mhj8/tHSjtFt9KgQAsHWMs+r8RTSzr0bXq+1JhTPq0I9NZq0Iy3oUDKITmf 3u0mjT+Ltrm0vQnEwcAyaura35+WqnciA5QQ4kESyoOB+8KhqHaqpNMmhHX15Ie+ YMNYHUn241Kqe3pkKBjlaDiLP9Hnxr+kyDCWex0reMtoEHwX8Kx23x+tBPh8C+g= =juZE -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG--