Hello
I finished writing this patch. I added test(and fnmatchcomp.m4 which I forgot
in previous). I didnt change much, prettied and fixed bugs discovered by tests.
Now it should be stable. I hope this patch looks OK.
Moreover I made two independent changes
first is preallocating buffer in fnma
Hello Ralf,
On Fri, May 01, 2009 at 09:50:23PM +0200, Ralf Wildenhues wrote:
> That NULTEST thing is cute but makes me cringe. If the second malloc
> runs out of memory, then you return, but leak memory from the first
> malloc. So in a tight memory situation, your code starts contributing
> to t
Hello Ondrej,
* Ondrej Bilka wrote on Fri, May 01, 2009 at 09:36:39PM CEST:
> +#define NULTEST(...) if (__builtin_expect(!(__VA_ARGS__),0)) return NULL;
> +#define NULTEST2(...) if (__builtin_expect(!(__VA_ARGS__),0)) return -1;
[...]
> +static fnmatch_state *
> +initfnmatchstate ()
> +{
> + fn
I send new version according to your comments
On Fri, May 01, 2009 at 02:51:48PM +0200, Bruno Haible wrote:
>
> Hmm, well, users are expecting a speedup through your module always. If it
> some (not too rare) cases the glibc fnmatch is faster, it's difficult to
> convince people to use your functio
Hello Ondrej,
Nice work already!
> *abc*
> en_US.UTF-8
> user: 2.71
> user: 0.23
> ...
> *ab[a-z]*
> en_US.UTF-8
> user: 2.85
> user: 3.32
> C
> user: 0.86
> user: 1.25
Hmm, well, users are expecting a speedup through your module always. If it
some (not too rare) cases the glibc fnmatch is
Hello Ondrej,
* Ondrej Bilka wrote on Thu, Apr 30, 2009 at 10:41:49PM CEST:
> I here attach compiled fnmatch I wrote as gnulib module.
I haven't read your patch closely, but it fails to check the return
value from all of the malloc/realloc... functions, opening up several
opportunities for segme
Hello
I here attach compiled fnmatch I wrote as gnulib module.
It always should give same answer as fnmatch.
Still I assume UTF8 or singlebyte encoding otherwise I fallback.
I could generalize this to wide characters but if I dont know any character is
single wchar I cannot do much (UTF16 wchar i
Ondrej Bilka wrote:
> I looked more into source and discovered fnmatch doesn't work as I imagined.
> By default it converts strings into widechars and match there.
> utf8 allows searching be done bitwise. Its in most cases faster.
fnmatch converts to wide characters because
On Fri, Apr 17, 2009 at 01:02:57PM +0200, Bruno Haible wrote:
> Hello Ondrej,
>
> > > Hello. I am writing partial fnmatch to speed up locate et al.
>
> Cool! We know for some time already that this is a bottleneck [1].
> I find it also interesting that you go for a two-step approach,
> preprocess
On Fri, Apr 17, 2009 at 11:47:20AM +0200, James Youngman wrote:
> On Thu, Apr 16, 2009 at 8:09 PM, Ondrej Bilka wrote:
> > Hello. I am writing partial fnmatch to speed up locate et al.
>
> >
> > Here is list what provided speedup and can be applied to original source
> >
> > FOLD causes worst per
Hello Ondrej,
> > Hello. I am writing partial fnmatch to speed up locate et al.
Cool! We know for some time already that this is a bottleneck [1].
I find it also interesting that you go for a two-step approach,
preprocess the pattern once and use it for matching often - the same
approach that we
[ CC += bug-findutils, bug-gnulib; bug-coreutils moved to BCC ]
On Thu, Apr 16, 2009 at 8:09 PM, Ondrej Bilka wrote:
> Hello. I am writing partial fnmatch to speed up locate et al.
Please note that locate is part of GNU findutils, not GNU coreutils.
I have CC'ed this email to the correct list.
12 matches
Mail list logo
