GNOME's Help Slow to Load

[Namaku Jiro]

Binary package hint: yelp

Try to open System > Preferences > Mouse (or Keyboard, Sound, Windows, etc). Click
'Help' button at the bottom left corner. The help window is appear immediately, but
the content take more than 10 seconds and 100% CPU usage on my 1.8 GHz computer.
There is no slow load with some other GNOME's apps like gcalc, gedit, etc though.

I don't know if this is the same bug as
https://bugs.launchpad.net/ubuntu/+source/gnome-doc-utils/+bug/23334
because that bug have already been solved since 2005.

BTW, I am using Interpid now.

[Pedro Villavicencio (pedro)]

that's known upstream, you can track it here: http://bugzilla.gnome.org/show_bug.cgi?id=388263

[VladimirCZ (vlabla)]

Will that be solved by replacing of Gecko with Webkit? As it is still quite slow and CPU intensive at first start of yelp, even in Ubuntu 9.10 64-bit on a dual core chipsets with 4 GB of RAM.

[Buck Evan (bukzor)]

I can confirm this, but my CPU usage shows much lower.

This is results of 'time yelp' where I close it right after it loads:

real 0m26.970s
user 0m2.000s
sys 0m1.444s

It took 27 seconds to show content, but only used 3.4s of CPU. This is only 12.5% utilization.

[Martin-Éric Racine (q-funk)]

Still affects Lucid. On This Centrino-based laptop with 2 GB of RAM, it takes more than a minute for the Yelp window to appear.

[Greg Merchan (gregory-merchan)]

Two of the bugs marked as duplicates of this bug should be reopened and reassigned to the package responsible for the System menu which contains the item About Ubuntu, because that item does not need to open the help browser. It could instead open an About dialog - like every other About menu item.

Those bugs are: bug #555549 and bug #474923 .

[Buck Evan (bukzor)]

This has been fixed upstream. We need someone to evaluate the new version and push it into Lucid, please.

From the developer:
Yelp 2.31.1 does not scan the filesystem on startup. Startup times are fast
again, and I won't add anything that blocks startup. So this is fixed.

Reference:
https://bugzilla.gnome.org/show_bug.cgi?id=388263#c11

[Zoubidoo (zoubidoo)]

bump.

Lucid is still running with version 2.30.0. Please push the new version that fixes >1 minute start-ups.

For new users, more than 1 minute to get help gives a real bad initial impression of Ubuntu. This bug should be higher priority.

[Fabián Rodríguez (magicfab)]

This won't likely make it into Ubuntu anytime before April 2011. Feature freeze for Maverick is *tomorrow* and by reading the upstream bug report you can see the progress so far. Around March/April 2011 we *may* be able to file an SRU for this. If anyone feels this is not the right information I'm happy to be corrected.

[Anthony Glenn (aglenn-pcug)]

Lucid still seems to have Yelp 2.30.0 (with the bug), as of today. If this bug is fixed in Yelp 2.31.1 then why not push that out as an update?

I was showing Ubuntu to someone who had never heard of Linux, the other day. And they wanted to know, "What is this Ubuntu thing?" So I did System > About Ubuntu. Well, how to make a bad first impression in one easy lesson, without even trying. This miserable Yelp thing took around 40 seconds to load, with nothing happening on screen until the last second or so. It is appalling ergonomics. I had to apologize, "Gee, I can't understand why this is taking so long -- it is taking even longer to start than Firefox. Sorry about that."

This long delay in Yelp starting is just not acceptable. Restarts are OK at around 2 seconds, but that first start is bad bad. Frankly, Yelp should be a tiny fraction of the size of Firefox and it should be reading relatively tiny data files. I expect under 1 second starts every time.

I want (1) Yelp really fixed, (2) this bug raised in importance. Other people are reporting having to wait over a minute. When you are looking for help, you are not sure what you are doing. To have the help system itself malfunctioning, that gives a very bad impression.

[Robert Roth (evfool)]

I agree with Anthony Glenn, the yelp fix should be in Maverick, it is indeed very important to have a responsive help system, and 40 s startup time for the help is not reasonable. @Fabian Rodriguez: Feature Freeze is in place, but there can be Feature Freeze exceptions: in the following cases(according to https://wiki.ubuntu.com/FeatureFreeze) : - is a reasonable fix for an important bug, - other exceptional circumstances, as judged by the release managers.
There are Feature freeze exceptions (https://wiki.ubuntu.com/FreezeExceptionProcess), the only thing is that it must be proved, that it won't break anything working right now.
Feature freeze exceptions should be filed as new bugs, with the following included:
-A description of the proposed changes, with sufficient detail to estimate their potential impact on the distribution
-A rationale for the exception, explaining the benefit of the change
-Any additional information which would be helpful in considering the decision
That can be done IMO, and it's worth a try.
See the details for reporting a feature freeze exception on the wiki page mentioned above.

[Robert Roth (evfool)]

Ok. I've done a bit of research... and I have sadly realized, that this can not be a featurefreeze exception :|. I have checked the Yelp release notes for the releases between 2.30 and 2.31.1, and the result is, that it might be possible to use that version, but it might be that the faster loading is because of the stripped-down yelp. Citing from the release notes:
"Changes in 2.31.1:
+------------------
+* Completely revamped document-focused interface
+* New mode to show extra information for editors
+* PackageKit install: links (experimental)
+* Use GSettings for settings storage
+* Temporarily missing features:
+ - man and info pages
+ - bookmarks
+ - full-text search
+ - printing
+ - list of installed help"

So it's better to have a help with a slow startup, but with more content (man and info pages are useful) and with search (help is mosttly for searching, and without full-text search, searching is ...), than to have a help without full-text search, bookmarks and without advanced content like man and info pages.

[Shaun McCance (shaunm-gnome)]

Just as a note: 2.31.1 was the *first* release in the 3.0 development series, made waaaaaay back in April. The only thing still missing is full-text search, which sucks, but: 1) the new quick search feature works well for most searches, and 2) full-text search in Yelp 2 is just as slow as everything else.

The current Yelp 3 builds use GTK+ 3, which won't have a stable release until December or so. Jorge Castro asked me at GUADEC if I'd make a branch of the Yelp 3 code that uses GTK+ 2, possibly scaling back the WebKitGTK+ dependency a bit, so that it could go into Maverick. It's still possible, but the level of accessibility support in the WebKitGTK+ version you're shipping is probably going to be a regression.

[Robert Roth (evfool)]

Thanks for your note. It was a bad idea indeed to look at release 2.31.1 because there were like 9 releases after that. I just thought that 2.31.1 has the least changes compared to 2.30 and it would be easy to backport.
I knew about the gtk3 dependencies, I was just thinking about backporting it to gtk2, but now I see a very small chance to have this fix (if we'd have it) as a feature freeze exception because of the lack of the proper accessibility support.

[Anthony Glenn (aglenn-pcug)]

Thanks to Shaun McCance for comment #12. I see what the trouble is. Yelp is setting itself up to display its full glorious range of capabilities before it starts drawing to the screen. Hence the long delay with nothing happening on screen. Make it draw its window, menu bar and the content of the help file as the first thing it does. Defer other processing until after the window and content are there on screen. Do the minimum possible amount of processing before starting to draw. Most users just want to see their help content as soon as possible, then do a bit of scrolling, go to the next page and that is about it. Make the common things fast and on the critical path. Defer processing for the uncommon things.

It is quite possible the user may never use some advanced features, such as search. It is wasteful to go to the trouble of setting something up, then throw away all that work when Yelp quits. Do not set advanced features up at all, until the user first asks to use them. On the subject of advanced features to defer or cut, I never use bookmarks, man and info pages or text search. Help Topics is used rarely.

I agree that it is a pain that GTK+ 3 is different from GTK+ 2. Further, I agree that GTK+ 3 gets used for new development. However, is it not the case that GTK+ 3 is a superset of GTK+ 2? So it should not be too difficult to use only GTK+ 2 for common actions, with advanced features which use GTK+ 3, simply left out. That would give a cut-down version of Yelp suitable for Lucid and Maverick. Fix this bug, at the cost of some features regressions. That would be a better option for most users than sticking with the present buggy version of Yelp. Yes, a few might be unhappy. Give those people instructions on how to go back to Yelp 2.30.0. I look forward to the next contribution by Shaun McCance.

[komputes (komputes)]

I'm counting 15 seconds for yelp to start up in Oneiric (Dell Inspiron 910, Atom 1.6Ghz, 512MB RAM).

[JC Hulce (soaringsky)]

Upstream fixed version has landed in Ubuntu