Zeal makes Xorg use 100% cpu

[LeonB]

I'm on Ubuntu 14.10 and when using Zeal from the ppa, after a few minutes, Xorg starts using 100% cpu.The weird thing is that the zeal process itself doesn't show much cpu usage in top.

[trollixx]

My guess would be, that there were something wrong with the old global hot key code, as it was the only place where we talked to X directly. That has been removed recently.

Hopefully, the problem is gone, but please reopen the report if the issue still persists.

[Shihira]

I have the same problem on my Fedora 20 and 21. I have two cores and everytime I open Zeal and read some docs (this means if I don't open any doc or just open one or two things will be okay), Xorg.bin starts to occupy one of them completely making my machine nearly frozen, and once I quit Zeal everything gets normal.

[trollixx]

@Shihira, what Zeal version did you try? If you build from sources, please give Qt WebEngine a try. Could be enabled with qmake CONFIG+=webengine.

[Shihira]

@trollixx , yes I just pull the latest commit adee352 and build from source. qmake CONFIG += webengine makes no difference. Adding CONFIG += webengine to src.pro leads to this error:

cd src/ && ( test -e Makefile || /usr/bin/qmake-qt5 /home/shihira/Software/Zeal/src/src.pro -o Makefile ) && make -f Makefile 
make[1]: Entering directory '/home/shihira/Software/Zeal/build/src'
/usr/bin/qmake-qt5 -o Makefile /home/shihira/Software/Zeal/src/src.pro
Project ERROR: Unknown module(s) in QT: webenginewidgets
Makefile:356: recipe for target 'Makefile' failed
make[1]: *** [Makefile] Error 3
make[1]: Leaving directory '/home/shihira/Software/Zeal/build/src'
Makefile:42: recipe for target 'sub-src-make_first-ordered' failed
make: *** [sub-src-make_first-ordered] Error 2

I suspected that if I have had some Qt libraries missed but yum search failed to find the word "webengine".

[asdrubalivan]

I built with CONFIG += webengine using the latest commit adee352, it made no difference. I'm using Fedora 21 with kernel 3.19.3-200.fc21.x86_64

[trollixx]

I am still trying to reproduce this problem, but Zeal works pretty stable on my ArchLinux and Ubuntu.

@asdrubalivan How did you obtain Qt WebEngine on Fedora? I don't see any packages available for it. Own build or binary from qt.io?

[asdrubalivan]

@trollixx: I used the qt5-qtwebkit 5.4.1 package. It seems it only happens on Fedora

[trollixx]

qt5-qtwebkit is not Qt WebEngine. It's not available from Fedora repositories. It's possible to download binary builds from qt.io, and check whether the problem still occur.

I can install Fedora in VirtualBox, but I am not sure it would reproduce the issue.

[DominicWatson]

I too am having the same problem on Korora 21 (based on Fedora 21) with Cinnamon desktop.

I've built from source from the master branch plus the 0.1 branch + the 0.1.1 tag all with the same problem. If I build with qmake CONFIG+=webengine the performance of the search itself completely dive bombs and becomes unusable.

I'm running a well spec'd Dell M3800 (quad core i7) and it really slows the OS down.

[trollixx]

I'd be really happy to hear any ideas about possible causes. I have Fedora 21 installed in VirtualBox, but I cannot reproduce the issue.

[Shihira]

@trollixx I sent you an email with a video attached illustrating how the problem is like on my machine. Hope it helps.

Repeatedly dragging scrollbar on the treeView and the search result listView raises CPU usage, no matter how short the list is. In the video we can see my desktop got into slow response and animations were delaying, CPU usage didn't reach 100% though. For clearing the suspicious of Qt, I opened Assistant and dragged repeatedly the listView there, which didn't have any impact.

[trollixx]

@Shihira Thanks! Indeed there's a major slowdown caused by the treeview item delegate. Now I need to figure out how to fix that.

For those willing to test, comment out the following line in src/ui/mainwindow.cpp (line 169 in 0.1 branch):

ui->treeView->setItemDelegate(new SearchItemDelegate(ui->lineEdit, ui->treeView));

[trollixx]

I've just pushed a partial fix for the delegate issue. Now it should not cause slowness when no search term is set.

[Shihira]

Thanks! This commit works well while not searching as expected.

[trollixx]

@Shihira What do you mean by not searching as expected? Another issue?

[Shihira]

@trollixx Sorry for my awful English. I'm not a native speaker. Please ignore the two words "as expected".

[trollixx]

@Shihira could you also pull all recent changes from 0.1 branch? It should work much better now even with search results.

It would be nice to hear back from multiple people to know whether issue is fixed or not.

[DominicWatson]

@trollixx I believe that the situation improved, but my system performance still degrades while running Zeal (just not crippled). I will try to provide some more detailed feedback when I can.

[Shihira]

I pulled ab317d0 and recompiled, regretfully, finding the performance problem in searching list is not yet fixed. I know too little about Xorg, but I'm still wondering why the CPU fixed high. Even if the delegate class occupies a large quantity of resources while rendering, CPU usage should have declined after I had the search result cleared.

[trollixx]

That's exactly what I see on my ArchLinux, relatively high (up to 60% on one core) CPU usage while I am doing some insane scrolling, but it drops immediately after I stop. So, the issue only occurs on Fedora as far as I can see, but even there not for everyone. For example, no problems with Zeal running on Fedora 21 in VirtualBox.

I would really appreciate any crazy ideas about possible reasons. Perhaps #265 is also related to the same problem.

[rajeebk]

I have installed latest 0.1.1 git on Fedora 21 x86_64 with qt5-qtwebkit and qt5-qtx11extras and here are some observations:

When typing one letter, the search list comes up pretty fast (<1sec to 2secs max), and CPU usage spikes only briefly then settles.
When typing multiple letters, the search list comes up very late (the delay in seconds is roughly about 3 times the number of letters typed) and the CPU usage spikes longer and higher.
When pasting a word into search form, again the list comes up relatively shortly, about 2 to 3 secs.

All I can say is maybe it is optimized to look for a single letter, and when typing more letters, the search process for every step of the formation of the word is done to completion before finally showing the list.

Is there a way to set a delay before a search process is initiated when starting to type, and/or cancel any previous searches in process?

[rajeebk]

Below is some hack I did to lessen the slow search and CPU usage. I just wanted to make the search process not run every time I type a letter, but only when pressing Return or something like that. It still takes 3 to 6 seconds to search all documents, but at least it doesn't multiply the delay by the number of keystrokes. When I also specifiy the document to search, it is instantaneous, e.g. "bash:return".
Some issue I found is that when a search returns nothing, subsequent Return keypress event does not get passed, so nothing is searched after that, even though I can type letters in the edit box. I had to click some other place or move the mouse outside the Zeal window to jumpstart the search.
One other issue is the error about calling some NetworkReply or something twice.
Anyway, I hope this hack will give some idea how to fix the real issue.

--- src/ui/mainwindow.cpp.orig  2015-11-05 14:27:24.000000000 -0800
+++ src/ui/mainwindow.cpp   2015-11-06 08:25:32.411610585 -0800
@@ -187,12 +187,13 @@
     setupSearchBoxCompletions();
     ui->treeView->setModel(m_zealListModel);
     ui->treeView->setColumnHidden(1, true);
+/*
     SearchItemDelegate *delegate = new SearchItemDelegate(ui->treeView);
     connect(ui->lineEdit, &QLineEdit::textChanged, [delegate](const QString &text) {
         delegate->setHighlight(Zeal::SearchQuery::fromString(text).query());
     });
     ui->treeView->setItemDelegate(delegate);
-
+*/
     createTab();
     /// FIXME: QTabBar does not emit currentChanged() after the first addTab() call
     reloadTabState();
@@ -255,10 +256,10 @@
         }
     });

-    connect(ui->lineEdit, &QLineEdit::textChanged, [this](const QString &text) {
+    connect(ui->lineEdit, &QLineEdit::editingFinished, [this]() {
+        const QString& text = ui->lineEdit->text();
         if (!m_searchState || text == m_searchState->searchQuery)
             return;
-
         m_searchState->searchQuery = text;
         m_application->docsetRegistry()->search(text);
         if (text.isEmpty()) {

[trollixx]

@rajeebk thanks for sharing your research!

I have to rewrite several core module to make this issue go away, notably docset indexing and parallel search. Unfortunately, I have no idea when I get enough time for that.

[trollixx]

There have been a lot of improvements made in search logic, UI responsiveness, and list item delegate has been completely rewritten to make it more efficient. I hope we can consider this fixed in the 0.3.0 release, which is coming shortly.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for a related request.