On 3/19/12 6:13 PM, Geir Hauge wrote:
> 2012/3/19 Chet Ramey :
>> I will look at optimizing that function, but it's always going to take time
>> to plow through 300K when you have to split it into words. (There's not
>> actually any word splitting of consequence happening with your second
>> examp
2012/3/19 Chet Ramey :
> I will look at optimizing that function, but it's always going to take time
> to plow through 300K when you have to split it into words. (There's not
> actually any word splitting of consequence happening with your second
> example using the pipeline.)
Letting compgen do
On 3/15/12 3:38 PM, Richard Neill wrote:
> Dear Bob,
>
> Thanks for your explanation. I do understand what is going on and why. But
> my point was that compgen has an implicit internal "grep" that is much less
> efficient than actual grep. Why is the performance of compgen's
> sorting/filtering al
On 3/14/12 1:44 PM, Richard Neill wrote:
> Dear All,
>
> I don't know for certain if this is a bug per se, but I think
> "compgen -W" is much slower than it "should" be in the case of a large
> (1+) number of options.
>
> For example (on a fast i7 2700 CPU), I measure:
>
> compgen -W "`seq 1
ad it wrong for some time.]
Best wishes,
Richard
Message: 4
Date: Wed, 14 Mar 2012 13:40:36 -0600
From: Bob Proulx
To: bug-bash@gnu.org
Subject: Re: compgen is slow for large numbers of options
Message-ID:<20120314194036.ga12...@hysteria.proulx.com>
Content-Type: text/plain; charset=us-asci
Richard Neill wrote:
> I don't know for certain if this is a bug per se, but I think
> "compgen -W" is much slower than it "should" be in the case of a
> large (1+) number of options.
I don't think this is a bug but just simply a misunderstanding of how
much memory must be allocated in order t
If I increase the upper number by a factor of 10, to 50, these times
become, 436 s (yes, really, 7 minutes!) and 0.20 s respectively. This
suggests that the algorithm used by compgen is O(n^2) whereas the
algorithm used by grep is 0(1).
I meant: grep is O(n).
Dear All,
I don't know for certain if this is a bug per se, but I think
"compgen -W" is much slower than it "should" be in the case of a large
(1+) number of options.
For example (on a fast i7 2700 CPU), I measure:
compgen -W "`seq 1 5`" 1794#3.83 s
compgen -W "`seq 1 5 |
