kdevelop 4 parsing on opensuse 11.2 is extremely slow for linux kerenl project
Andreas Pakulat
apaku at gmx.de
Sat Apr 3 13:56:53 UTC 2010
On 03.04.10 14:35:08, Milian Wolff wrote:
> Vadym Krevs, 03.04.2010:
> > On 3 April 2010 00:28, Milian Wolff <mail at milianw.de> wrote:
> > <snip>
> >
> > > But look at this: http://pastebin.com/bN2E8vxa
> > > It's actually getting called more than once ;-) And that's what makes
> > > things so horribly slow for custom make files. It's never occurred to us
> > > developers since all of us are only using cmake where this bottleneck
> > > doesn't occur. Oh and since it's executing an external app and waits for
> > > it to finish, it doesn't show up in callgrind _at all_ :-/
> >
> > Multiple make/gcc invocations in includePathResolver for custom make
> > file projects has been observed by users and reported to you more
> > than once already ... just like the fact that callgrind is useless for
> > I/O profiling.
> >
> > https://bugs.kde.org/show_bug.cgi?id=215968#c17
> > https://bugs.kde.org/show_bug.cgi?id=215968#c18
> > https://bugs.kde.org/show_bug.cgi?id=215968#c21
> > https://bugs.kde.org/show_bug.cgi?id=215968#c22
> > https://bugs.kde.org/show_bug.cgi?id=215968#c27
>
> Yeah you are right. Still I wonder how I can fix it, I've send David a mail and
> we'll se how we proceed. I'm personally for dumping the make-running part of
> the include path resolver and simply relying on the BuildManager (e.g. CMake)
> or the .kdev_include_paths files... But at least I should try to merge the six
> make runs to a single one and than cache it per dir. This should already
> decrease the time needed to parse a custom make project (Linux Kernel, Qt,
> ...) dramatically.
I'd like to add that for 4.1 we'll probably don't need the
include-path-resolver even for make-based projects as then the user will
get a proper configuration interface for setting up include paths for
his project and the various subdirs in it.
Andreas
--
You'll never see all the places, or read all the books, but fortunately,
they're not all recommended.
More information about the KDevelop-devel
mailing list