Re: sed query

2013-06-02 Thread Florent Peterschmitt
Le 31/05/2013 16:01, Chris Rees a écrit :
> Hi all,
> 
> I think I've discovered a strange behaviour of sed perhaps triggered
> by the length of a regex passed to it.  I noticed that a certain
> expression I passed took a very long time, and suspected the usual
> backtracking loop, so I started trimming it... and discovered this:
> 
> [crees@pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/por,,"
> /var/db/pkg/INDEX-9
> 4.699u 0.007s 0:04.70 99.7% 40+2733k 0+0io 0pf+0w
> [crees@pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/po,,"
> /var/db/pkg/INDEX-9
> 0.042u 0.000s 0:00.04 100.0% 48+3216k 0+0io 0pf+0w
> 
> I've looked at the code, and can't from a brief glance figure out why
> a slightly longer regex makes such a difference-- does it start to
> split it?
> 
> Chris

Uhu, maybe a bug that should be reported ?




signature.asc
Description: OpenPGP digital signature


Re: sed query

2013-06-02 Thread Eduardo Morras
On Fri, 31 May 2013 15:01:59 +0100
Chris Rees  wrote:

> Hi all,
> 
> I think I've discovered a strange behaviour of sed perhaps triggered
> by the length of a regex passed to it.  I noticed that a certain
> expression I passed took a very long time, and suspected the usual
> backtracking loop, so I started trimming it... and discovered this:
> 
> [crees@pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/por,,"
> /var/db/pkg/INDEX-9
> 4.699u 0.007s 0:04.70 99.7% 40+2733k 0+0io 0pf+0w
> [crees@pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/po,,"
> /var/db/pkg/INDEX-9
> 0.042u 0.000s 0:00.04 100.0% 48+3216k 0+0io 0pf+0w
> 
> I've looked at the code, and can't from a brief glance figure out why
> a slightly longer regex makes such a difference-- does it start to
> split it?

Perhaps second one uses memory cache data? Run both twice and show us the 
second times.


> Chris
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


---   ---
Eduardo Morras 
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: sed query

2013-06-02 Thread Chris Rees
On 2 June 2013 11:41, Eduardo Morras  wrote:
> On Fri, 31 May 2013 15:01:59 +0100
> Chris Rees  wrote:
>
>> Hi all,
>>
>> I think I've discovered a strange behaviour of sed perhaps triggered
>> by the length of a regex passed to it.  I noticed that a certain
>> expression I passed took a very long time, and suspected the usual
>> backtracking loop, so I started trimming it... and discovered this:
>>
>> [crees@pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/por,,"
>> /var/db/pkg/INDEX-9
>> 4.699u 0.007s 0:04.70 99.7% 40+2733k 0+0io 0pf+0w
>> [crees@pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/po,,"
>> /var/db/pkg/INDEX-9
>> 0.042u 0.000s 0:00.04 100.0% 48+3216k 0+0io 0pf+0w
>>
>> I've looked at the code, and can't from a brief glance figure out why
>> a slightly longer regex makes such a difference-- does it start to
>> split it?
>
> Perhaps second one uses memory cache data? Run both twice and show us the 
> second times.
>

Nope, same.

[crees@pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/por,,"
/var/db/pkg/INDEX-9
4.703u 0.007s 0:04.85 96.9% 40+2732k 210+0io 0pf+0w
[crees@pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/por,,"
/var/db/pkg/INDEX-9
4.748u 0.007s 0:04.75 99.7% 40+2732k 0+0io 0pf+0w

I also get the same on head;

[crees@medusa]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/por,,"
/var/db/pkg/INDEX-10
7.813u 0.015s 0:07.96 98.2% 40+183k 0+0io 0pf+0w
[crees@medusa]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/po,,"
/var/db/pkg/INDEX-10
0.070u 0.000s 0:00.07 100.0% 45+205k 0+0io 0pf+0w
[crees@medusa]~% uname -a
FreeBSD medusa 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r250009: Thu May
30 10:11:16 BST 2013 root@medusa:/usr/obj/usr/src/sys/MEDUSA
amd64

Chris
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: >3955MiB of swap space

2013-06-02 Thread dt71

On 05/27/2013 19:59, d...@gmx.com wrote:

I have 4 hard drives, each containing a swap partition of size 1023MiB. I get:

warning: total configured swap (1178880 pages) exceeds maximum recommended 
amount (1012480 pages).
warning: increase kern.maxswzone or reduce amount of swap.


I am yet to hear whether the warning is safe to ignore. Which one of the 
following is true?

(1) Only 3955MiB of swap space will be used (instead of 4092MiB), but that 
reduced space will have maximum operational performance.

(2) 4096MiB of swap space will be used, at reduced performance. To increase 
performance, the partitions have to be resized to (3955/4)MiB each.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: sed query

2013-06-02 Thread Florent Peterschmitt
Le 02/06/2013 14:16, Chris Rees a écrit :
> On 2 June 2013 11:41, Eduardo Morras  wrote:
>> On Fri, 31 May 2013 15:01:59 +0100
>> Chris Rees  wrote:
>>
>>> Hi all,
>>>
>>> I think I've discovered a strange behaviour of sed perhaps triggered
>>> by the length of a regex passed to it.  I noticed that a certain
>>> expression I passed took a very long time, and suspected the usual
>>> backtracking loop, so I started trimming it... and discovered this:
>>>
>>> [crees@pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/por,,"
>>> /var/db/pkg/INDEX-9
>>> 4.699u 0.007s 0:04.70 99.7% 40+2733k 0+0io 0pf+0w
>>> [crees@pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/po,,"
>>> /var/db/pkg/INDEX-9
>>> 0.042u 0.000s 0:00.04 100.0% 48+3216k 0+0io 0pf+0w
>>>
>>> I've looked at the code, and can't from a brief glance figure out why
>>> a slightly longer regex makes such a difference-- does it start to
>>> split it?
>>
>> Perhaps second one uses memory cache data? Run both twice and show us the 
>> second times.
>>
> 
> Nope, same.
> 
> [crees@pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/por,,"
> /var/db/pkg/INDEX-9
> 4.703u 0.007s 0:04.85 96.9% 40+2732k 210+0io 0pf+0w
> [crees@pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/por,,"
> /var/db/pkg/INDEX-9
> 4.748u 0.007s 0:04.75 99.7% 40+2732k 0+0io 0pf+0w
> 
> I also get the same on head;
> 
> [crees@medusa]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/por,,"
> /var/db/pkg/INDEX-10
> 7.813u 0.015s 0:07.96 98.2% 40+183k 0+0io 0pf+0w
> [crees@medusa]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/po,,"
> /var/db/pkg/INDEX-10
> 0.070u 0.000s 0:00.07 100.0% 45+205k 0+0io 0pf+0w
> [crees@medusa]~% uname -a
> FreeBSD medusa 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r250009: Thu May
> 30 10:11:16 BST 2013 root@medusa:/usr/obj/usr/src/sys/MEDUSA
> amd64
> 
> Chris

Yes I tried too on -current. And I tried also on GNU/Linux and there
isn't this problem. Is it gnu or bsd sed ?




signature.asc
Description: OpenPGP digital signature


Re: sed query

2013-06-02 Thread Chris Rees
On 2 June 2013 18:15, Florent Peterschmitt  wrote:
> Le 02/06/2013 14:16, Chris Rees a écrit :
>> On 2 June 2013 11:41, Eduardo Morras  wrote:
>>> On Fri, 31 May 2013 15:01:59 +0100
>>> Chris Rees  wrote:
>>>
 Hi all,

 I think I've discovered a strange behaviour of sed perhaps triggered
 by the length of a regex passed to it.  I noticed that a certain
 expression I passed took a very long time, and suspected the usual
 backtracking loop, so I started trimming it... and discovered this:

 [crees@pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/por,,"
 /var/db/pkg/INDEX-9
 4.699u 0.007s 0:04.70 99.7% 40+2733k 0+0io 0pf+0w
 [crees@pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/po,,"
 /var/db/pkg/INDEX-9
 0.042u 0.000s 0:00.04 100.0% 48+3216k 0+0io 0pf+0w

 I've looked at the code, and can't from a brief glance figure out why
 a slightly longer regex makes such a difference-- does it start to
 split it?
>>>
>>> Perhaps second one uses memory cache data? Run both twice and show us the 
>>> second times.
>>>
>>
>> Nope, same.
>>
>> [crees@pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/por,,"
>> /var/db/pkg/INDEX-9
>> 4.703u 0.007s 0:04.85 96.9% 40+2732k 210+0io 0pf+0w
>> [crees@pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/por,,"
>> /var/db/pkg/INDEX-9
>> 4.748u 0.007s 0:04.75 99.7% 40+2732k 0+0io 0pf+0w
>>
>> I also get the same on head;
>>
>> [crees@medusa]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/por,,"
>> /var/db/pkg/INDEX-10
>> 7.813u 0.015s 0:07.96 98.2% 40+183k 0+0io 0pf+0w
>> [crees@medusa]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/po,,"
>> /var/db/pkg/INDEX-10
>> 0.070u 0.000s 0:00.07 100.0% 45+205k 0+0io 0pf+0w
>> [crees@medusa]~% uname -a
>> FreeBSD medusa 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r250009: Thu May
>> 30 10:11:16 BST 2013 root@medusa:/usr/obj/usr/src/sys/MEDUSA
>> amd64
>>
>> Chris
>
> Yes I tried too on -current. And I tried also on GNU/Linux and there
> isn't this problem. Is it gnu or bsd sed ?
>

BSD sed, GNU sed doesn't show this;

[crees@pegasus]/usr/ports/textproc/gsed% time gsed -ne
"s,^BitchX-[0-9][^|]*[\|]/usr/por,," /var/db/pkg/INDEX-9
0.019u 0.009s 0:00.04 25.0% 408+6132k 1+0io 2pf+0w

Chris
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: sed query

2013-06-02 Thread Adrian Chadd
... so run it inside hwpmc and see what the resulting CPU users are?



adrian

On 31 May 2013 07:01, Chris Rees  wrote:
> Hi all,
>
> I think I've discovered a strange behaviour of sed perhaps triggered
> by the length of a regex passed to it.  I noticed that a certain
> expression I passed took a very long time, and suspected the usual
> backtracking loop, so I started trimming it... and discovered this:
>
> [crees@pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/por,,"
> /var/db/pkg/INDEX-9
> 4.699u 0.007s 0:04.70 99.7% 40+2733k 0+0io 0pf+0w
> [crees@pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/po,,"
> /var/db/pkg/INDEX-9
> 0.042u 0.000s 0:00.04 100.0% 48+3216k 0+0io 0pf+0w
>
> I've looked at the code, and can't from a brief glance figure out why
> a slightly longer regex makes such a difference-- does it start to
> split it?
>
> Chris
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: >3955MiB of swap space

2013-06-02 Thread Wojciech Puchar
warning: total configured swap (1178880 pages) exceeds maximum recommended 
amount (1012480 pages).

warning: increase kern.maxswzone or reduce amount of swap.


I am yet to hear whether the warning is safe to ignore. Which one of the 
following is true?


(1) Only 3955MiB of swap space will be used (instead of 4092MiB), but that 
reduced space will have maximum operational performance.


this. or just increase kern.maxswzone



(2) 4096MiB of swap space will be used, at reduced performance. To increase 
performance, the partitions have to be resized to (3955/4)MiB each.


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"



___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"