Le 02/06/2013 14:16, Chris Rees a écrit : > On 2 June 2013 11:41, Eduardo Morras <emorr...@yahoo.es> wrote: >> On Fri, 31 May 2013 15:01:59 +0100 >> Chris Rees <utis...@gmail.com> 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
