Performance problems in CMake support

[Aleix]

On 4/2/08, Robert Knight <robertknight at gmail.com> wrote:
> Hi,
>
>  I notice there are places in the code where QRegExp are constructed with
>  a constant pattern argument on each function invocation.
>
>  eg.  string.indexOf(QRegExp("somepattern"));

I can't see where this is used...

>
>  QRegExp initialization is expensive so if possible, moving the QRegExp
>  to a static class member which is only initialized once should help.
>  The actual pattern matching against a string seems to be quite fast
>  (assuming Qt was build with optimizations enabled.  QRegExp is much,
>  much slower in debug-only builds)
I think we are all using debug compilations here...

>
>  What I think Aleix is getting at is that a lot of time seems to be spent
>  in QDir::entryInfoList() to find various libraries and other files.
>  QDir::entryInfoList() uses QDirIterator which spends a lot of time
>  constructing QRegExps to do the filter matching.

I'm "only" using this method when running a find_library() because
there was the case that the library.so didn't exist but the
library.so.666 existed and I needed the wild card. Well, I don't know
if I needed it but it was a proper solution...

>
>  For reference, this is the full callgrind output I got from loading the
>  KDevelop 4 project.
>
>  http://www.robertknight.me.uk/files/temp/cmake-parser-profile.tar.gz
I've profiled it many times, but thanks :) good to have.

>
>  Regards,
>
> Robert.

Thanks,
Aleix

>
>
>
>  On Tue, 2008-04-01 at 16:35 +0200, Aleix wrote:
>  > I have removed (and commited) the QRegExp's from the envvar and the
>  > definitions. I've tested it when loading kdebase and it doesn't make
>  > any difference.
>  >
>  > I still hope that using the cache it will be a little faster. :P
>  >
>  > Bye,
>  > Aleix
>  >
>  > On Tue, Apr 1, 2008 at 4:11 PM, Andreas Pakulat <apaku at gmx.de> wrote:
>  >         On 01.04.08 15:48:39, Aleix wrote:
>  >         > If you grep QRegExp on the parser directory you will see
>  >         that it is only on:
>  >         > - CMakeAst, command parser:
>  >         >     * To collect the cmake_minimum_required version value.
>  >         >     * The same for cmake_policy (2.6)
>  >         > - Condition evaluator:
>  >         >     * For the MATCHES case (from cmake, can't remove it).
>  >         > - Project Visitor:
>  >         >     * To get the information from the envvar list (it could
>  >         be changed, and
>  >         > I will, but I don't think it is significant)
>  >         >     * On the STRING command on regex-related options.
>  >         >     * ADD_DEFINITION command: to extract info from the
>  >         definitions. (it
>  >         > could be changed, and I will, it appears quite often so
>  >         maybe it could be
>  >         > significant)
>  >         >     * REMOVE_DEFINITION command: the same but barely used.
>  >         >
>  >         > It is used on the manager 1 time so it is not a problem as
>  >         well.
>  >         >
>  >         > I'll remove now the few I think that could be removed but,
>  >         as I said, I
>  >         > think the big load of regex is used by the cmake scripts
>  >         themselves.
>  >
>  >
>  >         Ok, so maybe we should think about not using Qt's regex
>  >         support, but
>  >         instead something else, like pcre? Or check what cmake itself
>  >         uses.
>  >
>  >         Andreas
>  >
>  >         --
>  >         You are fighting for survival in your own sweet and gentle
>  >         way.
>  >
>  >
>  >         _______________________________________________
>  >         KDevelop-devel mailing list
>  >         KDevelop-devel at kdevelop.org
>  >         https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>  >
>  >
>  > _______________________________________________
>  > KDevelop-devel mailing list
>  > KDevelop-devel at kdevelop.org
>  > https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
>
>  _______________________________________________
>  KDevelop-devel mailing list
>  KDevelop-devel at kdevelop.org
>  https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>