Re: Extended globbing seems to have become much slower in recent versions of Zsh

[Jesper Nygårds <jesper.nygards@xxxxxxxxx>]

I see no real difference with or without Peter's patch, I'm afraid.

I will incorporate the suggestions from Bart in my solution. But I feel I
haven't explained very well (or at all) what I'm trying to achieve. I use
this kind of globbing in a sort of "recursive grep" which I use
interactively to grep in my project's codebase. The inputs to the script
include both patterns that I search for and patterns that I want to
exclude. Up until now, I have composed the list of exclusions from the
input without separating ordinary files from directories, but Bart's tip
made me aware that such a separation would be worth doing to make it faster.

As a side note, since I have implemented this in zsh, I followed what I
thought was "zsh best practice", and composed this rather complicated file
list with a zsh glob expression, instead of relying on an external command
such as gnu "find". But after I discovered this bottle neck in my scripts,
I have experimented with instead letting "find" find the files, and indeed
that seems a whole lot faster. I mention that just to be sure that I am not
causing you to waste your time if my use case is so extreme that it's not
worth bothering about its performance.


On Sun, Mar 6, 2016 at 7:10 PM, Peter Stephenson <
p.w.stephenson@xxxxxxxxxxxx> wrote:

> On Sat, 5 Mar 2016 09:47:23 -0800
> Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > On Mar 4,  9:49pm, Peter Stephenson wrote:
> > } Subject: Re: Extended globbing seems to have become much slower in
> recent
> > }
> > } This is what I meant.  It may not be related to the slow down in
> > } question, but it should speed up repeated use of exclusion patterns in
> > } any case.
> >
> > Sadly, on my desktop this actually SLOWS DOWN the process even further.
> > The below is for a glob of 13,000 files (largest/deepest tree I have
> > handy) with "repeat 3" and Jesper's pattern:
>
> That suggests either I've made a mistake in the optimisation portion
> (which I didn't explicit test, only that it gave the correct behaviour),
> or the repeated allocation ad nfreeing of similar length strings is
> close to optimal in allocation already... or a combination.
>
> pws
>