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