Re: 1.7] BUG - GREP slows to a crawl with large number of matches on a single file

[Thomas Wolff]

[forgot to CC to bug-grep before, so I'm resending this, with one more 
comment, and leaving out cygwin-specific parts]

Corinna Vinschen wrote:
> On Nov  6 16:00, Thomas Wolff wrote:
>  
> > > ...
> > >       
> > I extended your test program to demonstrate the inefficiency of the
> > standard mbrtowc function. [...]
> >     
I later had to correct:
> Anyway, corrected results are still by a factor of 3 to 4 in favor of 
> my algorithm. 
Corinna wrote:
> That's sort of an unfair test.  Your utftouni function doesn't care for
> mbstate, error, and surrogate pair handling.
>   
This is a question of use cases:
* mbstate is needed e.g. if you feed results of read() which possibly 
come in arbitrary chunks directly into mbtowc(); it's not needed if you 
only transform complete lines of text at once. The stdlib function is a 
little bit too generic (and thus complicated, too) for many applications.
* error handling is there, in my function; it's simplified, incorrect 
sequences are all mapped to 0 for the test case but they could as well 
return an error indication without performance impact.
* surrogate pair handling is only needed if you pass the string from/to 
the Windows API. It's not needed for POSIX applications (provided 
wchar_t would be sufficiently wide). So if wchar_t can be extended in 
the newlib API, it might be useful to have two implementations; one for 
applications (w/o surrogates), one for cygwin itself.


[...]

My main point was that, depending on the use case, some applications 
would be better off using less generic, optimized functions.
The kind of dogmatic suggestion (as seen in the "locale scene") that 
everybody should use the stdlib wide character functions is often 
misleading.
grep and sed would certainly be well advised to change that.

Thomas