Summary: | KDevelop parses deeply nested template aliases for an extremely long time (indefinitely) | ||
---|---|---|---|
Product: | [Applications] kdevelop | Reporter: | Igor Kushnir <igorkuo> |
Component: | Language Support: CPP (Clang-based) | Assignee: | kdevelop-bugs-null |
Status: | REPORTED --- | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | 5.10.221201 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
See Also: | https://bugs.kde.org/show_bug.cgi?id=399783 | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
The slowly-parsed test file from the LLVM repository
Not yet working and probably unneeded workaround attempt |
Description
Igor Kushnir
2023-01-12 15:35:37 UTC
do you have an idea on how we could possibly detect such cases to prevent them from slowing things down extremely? (In reply to Milian Wolff from comment #1) > do you have an idea on how we could possibly detect such cases to prevent > them from slowing things down extremely? A separate (dedicated or main) thread could time all running parse jobs and abort those that run longer than a minute. A parse-aborting mechanism already exists: ParseJob::abortRequested(). The atomic abortRequested variable can be passed to the Visitor and checked in slow functions where the checks wouldn't harm performance much, such as createClassTemplateSpecializationType(). (In reply to Igor Kushnir from comment #2) > abort those that run longer than a minute. The maximum allotted time can be configurable of course. On the Configure-KDevelop=>Language Support=>Background Parser tab, I think. Created attachment 155263 [details] Not yet working and probably unneeded workaround attempt Just tried to implement aborting very-long-running parse jobs. Doesn't work properly. I suspect a separate custom aborting mechanism should be used instead of the existing ParseJob::requestAbort() one to avoid reparsing and RAM exhaustion. That is, a separate atomic variable should be used for Visitor::createClassTemplateSpecializationType(), possibly set up in this function too. However, now I think the code should be optimized instead of working the slowness around. I suspect that the LLVM test exposes gross inefficiency in KDevelop: instead of remembering and reusing already created class template specialization types/aliases, each new occurrence is created from the start. Apparently this inefficiency has been eliminated in Clang years ago. KDevelop should follow suit. Perhaps such an optimization can noticeably improve background parsing performance for normal non-test files too. For example, it could fix Bug 399783. before we do such hackery, let's first try to optimize the code. I'm looking into that now https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/424 has a fix for the file here, if there are other's like it that are still slow afterwards please tell me :) (In reply to Igor Kushnir from comment #0) > A workaround that I hope will prevent background parser freezes is to exclude > the "/clang/test/*/" pattern in the Project Filter. This workaround does work: with the test dir pattern exluded the LLVM project has been parsed successfully and KDevelop exited within seconds. |