https://bugs.kde.org/show_bug.cgi?id=384876

            Bug ID: 384876
           Summary: project import inefficiency
           Product: kdevelop
           Version: unspecified
          Platform: Compiled Sources
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
          Assignee: kdevelop-bugs-n...@kde.org
          Reporter: rjvber...@gmail.com
  Target Milestone: ---

These are observations by Sven Brauch taken from a phabricator review. Not
taking credit, nor taking the challenge to address the reported issue just yet.
I may in due time if no one more qualified beats me to it.

The observations probably pertain to the cmake project plugin, in "CMake
Server" mode (which is roughly 4x slower than the json-based importer in my own
benchmarks).

>>>>>>

It indeed takes ages to import the project, and I couldn't figure out why ...
it is certainly not CPU load. I looked in perf, the CPU time spent in importing
the project is quite low.
In fact, the code model generation (which seems to be the last step in the
import AFAIU) finishes relatively quickly here (after something like 5
seconds), but then it still takes like 30 seconds for the import to finish. I
don't know where that time is spent.

This is a bug, something is waiting too long for something else. Let's find the
bug instead of introducing checkboxes to work around it.

Here's the two things that are broken and need fixing:

1. FileManagerListJob has a queue of directories to list. It processes those
sequentially, and after listing each, it goes through the event loop (async
slot invocation) to list the next. This takes aaaaaages for lots of directories
to list, which are mostly spent waiting and not in actual CPU time. When doing
this synchronously as a test, it takes maybe half a second instead of 30
seconds.
2. The reason this is noticeable now is that for some reason, it lists all the
build dirs. This is probably a bug in the new cmake importer, they should not
be listed.

Fixing the second point would solve the problem, but fixing the first one
somehow (just making it sync isn't a solution, but there is certainly a better
way) would also be very nice since it will further speed up the import.
The first point is IMO the much worse bug, since that is what will cause large
project imports (think clang) be very slow in either case. For completely no
reason whatsoever.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to