Performance problems in CMake support

[Aleix]

I've seen that using:
QFile::exists(file.toLocalFile())
instead of the
!entryList("filename.*").isEmpty()

makes kdebase last 26s instead of 35s which is a very noticeable
change. But, as you might imagine, it is not correct.

Do you know any other way to look for all the libsmth.so*? I've
managed to improve the filters a bit and left it to 30s, but it is not
as good as we need yet. :)

This makes me think of something, btw. If there is such a bottleneck
here when findinf files, maybe the cache will be a good solution to
the problem...

Night night!
Aleix

On 4/2/08, Aleix <aleixpol at gmail.com> wrote:
> 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
>  >
>