Zsh Mailing List Archive
Messages sorted by:
Re: [BUG] APPEND_HISTORY leads to complete reread + rewrite of histfile
- X-seq: zsh-workers 42089
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: "zsh-workers@xxxxxxx" <zsh-workers@xxxxxxx>
- Subject: Re: [BUG] APPEND_HISTORY leads to complete reread + rewrite of histfile
- Date: Wed, 6 Dec 2017 11:51:02 -0800
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=BfeEq6qG6Z6ZmOM78YmDYg688xyF5K65nZJrl20fWyM=; b=SUfnPPH6n6MAmOIACDjVcKGlLTuB2Sf/uBz7WO1IISXRFc775EhJwMKbl9FNTKgK7W CAZjlsz9H3u9mQr9xLqy2+LGUzTIS7xuILvrDDCovZ1BqZUxGyhF6drKJ11tAyCn4By3 HA79vb7h2ndYao5IFgqvW8yKU63WKSdOq7wHQ/423AbHZIucnRUI08jaMGS12RbVg9Of H7qDelu5JZaBYJLLg1PrgCej0Qj/gEJfENtUjWT0m50eOGWzL2NSCaRWlBpiJgSltiX1 LJLTAN9FeAOmHyG5/tjinTQXVq/RtvKiYAbwU9NAE5yz93EndwZPf+Bfjqd5bOp6HH6V 5YrA==
- In-reply-to: <20171206193122.w4r3dhkotlhdtrah@local>
- List-help: <mailto:email@example.com>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- List-unsubscribe: <mailto:email@example.com>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <20171206193122.w4r3dhkotlhdtrah@local>
On Wed, Dec 6, 2017 at 11:31 AM, Zeshy <ml.zsh@xxxxxx> wrote:
> Hi all!
> In search of the reason why zsh (5.4.2 and fairly recent git) is
> so much slower reading/writing larger history files (13 MB, 330k lines)
> than bash (4.4.12), I think I found a bug. If I missed something (like
> some option), and this is not a bug, but just misconfiguration, or if
> you need more information, please let me know.
This happens because of HISTSIZE and the various HIST_*DUP* options.
The only way to do duplicate filtering is to examine the entire past
history, and there's no setting of HISTSIZE that is interpreted as
"unlimited" so rewriting to output only the most recent $HISTSIZE
lines is always performed.
It would probably be possible to optimize for the case of "$HISTSIZE
is larger than the current number of lines and no duplicate removal is
enabled" but right now there is just one rewriting algorithm that
applies (or not) those conditions internal to the loop.
So not technically a bug but not optimized for people who can "afford"
the memory cost to have every shell preserve huge amounts of history.
Messages sorted by: