https://bugs.kde.org/show_bug.cgi?id=464198
--- Comment #4 from Igor Kushnir <igor...@gmail.com> --- Created attachment 155263 --> https://bugs.kde.org/attachment.cgi?id=155263&action=edit 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. -- You are receiving this mail because: You are watching all bug changes.
