-
Nikolai Kosjar authored
Having *some* limit is reasonable since sorting happens in the UI thread and given enough includes/symbols it will freeze sooner or later. The strategy is now: Stop sorting at all if there are more than 30.000 completion items to process. The limit is a guess made on the following measurements. The goal is to keep below 100ms. test | items | before | now -----+----------------------- Cpp1 | 6394 | 172ms | 15ms | Win1 | 44739 | 125ms | 56ms | Qtc1 | 9648, | 16ms | 15ms | Qtc2 | 10210 | 20ms | 16ms | Qtc3 | 51044 | 141ms | 63ms | Qt1 | 62953 | 172ms | 78ms | Windows.h alone pulls in about 44.000 completion items. Used test procedure ------------------- For each test below, do: 1. Start Qt Creator in release mode 2. Open/create the project with a MSVC2015 Kit 3. Open the mentioned file 4. Strg+Space in the mentioned function Measured with a timer in IpcReceiver::codeCompleted. Test projects: Cpp1: stdc++11-includes.pro, main.cpp, main() Win1: Create project from wizard, *.cpp file including windows.h, completion in some added function Qtc1: qtcreator.pro, texteditor.cpp, BaseTextEditor::duplicate() Qtc2: qtcreator.pro, fakevimhandler.cpp, FakeVimHandler::jumpToLocalMark Qtc3: qtcreator.pro, botan.cpp, version_string() Qt1: qt-essential-includes.pro, main.cpp, main() Change-Id: I6fbd65d14f6086f289be7dd6c24385996e4bde83 Reviewed-by: Tim Jenssen <tim.jenssen@qt.io> Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
4ae368dd