Community
Participate
Working Groups
A consistent complaint with the Eclipse Help system is that it can take a long time to build the first search index (especially when many plugins are installed), which is a particular pain because it is only kicked off after a user has indicated he wishes to search for something. I'm wondering if we can check for the help index on startup. If index DNE or if new plugins have been installed, the indexing process is started as a non-blocking thread. If a user attempts a search while the index process is still running in background, the help system can present a message (similar to what exists now) informing a user that they must wait for indexing to complete, and presenting a progress bar (which can get current progress status from the monitor watching the non-blocking index process). In 99% of the cases, the indexing will complete while someone's looking through the welcome perspective or building their first project, and be ready by the time they actually want to run a search. Really easy win in terms of usability.
Yes. We were thinking about it, since Eclipse added jobs support in 3.0. In the mean time a product can ship prebuilt help index which will speed up indexing after initial installation.
In many uses of Eclipse, the documentation plugins installed depend on which components are installed, making a pre-built index near impossible to do (as I understand things). Glad to know you're considering this support, as it would really help.
We should definitely consider this for 3.1. Help view already kicks the indexer when opened, so we already have the model implementation as a background job. All we need to do is expand it to other areas of help (Help>Help Contents menu item etc.).
Dejan, is that new in the 3.1 milestone builds? The 3.0.1 driver (just downloaded and tested) doesn't kick off the indexing until a user opens help and attempts a search ...
This is the new function appearing in today's integration build and only when opening the new Help view (for now, press F1 anywhere in the workbench window). Again, we cannot start the indexer on the very startup because that would be not be in the spirit of Eclipse to use lazy loading as much as possible. However, starting the indexer when any of the help actions is invoked seems fair.
Cool! I see your point about lazy-loading. Could we still provide a mechanism for the indexer to be called by a product *built* on Eclipse (no names, no names ;)) which might make the product-level decision to have that indexer called on first startup in order to ensure that users have a zero-wait time if they want to do a help search?
Eclipse Help system is just the default implementation of the AbstractHelpSystem class. Therefore, you don't really call Eclipse help system, you talk to Platform UI proxy and it delegates the call to the active help system that implements AbstractHelpSystem class. In order for this to work, we would need to add a new method, something like: ensureSearchIndexed(); The method would immediately exit if no indexing is needed. Otherwise, it would start indexer in a background job.
Dejan, that method exposes the internals of help. Indexing is just an artifact of doing a (waaaay faster) search. I suggest we provide a search API, that in turns triggers a background indexing. A product can search for a something, just to kick things off. If this looks too hackerish, than an init() method should do it.
Although it is true that indexing is internal artifact of Lucene, virtually every search engine must use it in order to perform well. I think that your suggestion to name the method 'init' is very good - it is general enough and would cover indexing and anything else that a help system would need to run.
So do we need to close this bug and open a new one with the requirements listed above? That is to say a small search API added to the platform UI proxy which includes an init() method that will ensure that the system is indexed and ready for search? Then applications based on Eclipse can simply call that init() method using their their own criteria in order to decide when they'd want to do that.
The only feature request from this discussion would be addition of 'init' method on IHelpSystem and AbstractHelpSystem classes, AbstractHelpSystem would provide default (empty) implementation for backward compatibility.
OK, renamed so that the bug title better reflects the request. :)
Due to the complexity of checking the index for an ISV and the requirement to NOT use the existing calls in org.eclipse.help.base plug-in, we are going to provide the startup plug-in ourselves. This defect will be used to track this new feature. The proposal is to create a new optional RCP plug-in (org.eclipse.help.indexer) that would check the relevant configuration files and start a background job if indexing is needed. The plug-in will prereq org.eclipse.help.base but it will only create classes from it if indexing is required. The goal is to perform a quick I/O check and exit if no indexing is needed. If indexing IS needed, we will create IndexerJob, schedule it and exit. Either way, the actual indexing will be performed by the background job whose progress can be monitored as with any other job. This same job is created when HelpView is opened, so checks will be performed to avoid duplication. The name of the new plug-in will be : org.eclipse.help.indexer It will have a 'startup' extension that will case the execution on workbench startup. It will not really perform the indexing (org.eclipse.help.base does that) but we don't want to create a verbose plug-in name for the sake of exactness.
We have decided to drop this idea and instead go with the prebuit index per plug-in. The overhead of building an index in the background thread on startup may be too much on some platforms (on Linux GTK, priority is not given to the GUI thread so the apparent performance may be bad for several minutes). See bug 57455 for more information on prebuilt indexes.
