Request for review: Grepview plugin rewrite

Syron mr.syron at googlemail.com
Sat Aug 28 11:13:03 UTC 2010


> That only works if pcre has been built with utf8 support as far as I
> could see. What happens if its built without utf8 support? IMHO we
> should use QRegExp unless you can prove in that plugin that searching
> with QRegExp is much slower than PCRE on a codebase like kdevplatform.
> With not too-simple regexps. Also note that conversion between some
> char* and QString (in particular when also converting encoding) is also
> costly..

utf8: If pcrecpp has not been compiled with utf8 support, the flag is
simply ignored and a simple ascii search is performed.
Performance: I did some perfomance test with 38k files. QRegExp and
pcre have nearly the same speed, but as soon as the regexp gets
complicated, pcre is much faster than QRegExp.
For fun I tested all combinations of QFile/std::ifstream and
QRegExp/pcre, and the fastest is the QFile/pcre combination, even with
conversions.
When I searched for "void\s*[a-zA-Z_]+\s*(::\s*[a-zaA-Z_]+\s*)?\(.\)",
QRegExp needed 31s, while pcre needed 26s. When searching for
"\belse\b", QRegExp needed 3m5s, pcre needed 3m21s.
And well, about the encoding: KDevelop aims at developing, so I don't
think that there is much use of encodings, due to the fact that most
programs are written in English and the compilers only accept
identifiers with standard ascii encoding.
-- Syron




More information about the KDevelop-devel mailing list