Details
-
Type:
Improvement
-
Status:
Resolved
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: eclipse-1.0
-
Component/s: Eclipse Support
-
Labels:None
-
Testcase included:yes
-
Number of attachments :
Description
The eclipse plugin sets up a cache containing all step candidates. This cache is rebuilt whenever something changes within the project (which sometimes is happening at every key-stroke). Since querying the cache is bound to waiting for a reload to complete, this affects the GUI/user thread, ending up in a slow or even locked up Eclipse.
Reported as per Github issues
- #6 https://github.com/jbehave/jbehave-eclipse/issues/6
- possibly also related to #1 https://github.com/jbehave/jbehave-eclipse/issues/1
Github pull request: https://github.com/jbehave/jbehave-eclipse/pull/10
This code detaches the query of the cache from its reload; Querying it is always done directly on the last known one, any change in the project requests an asynchronous reload, with only one active at a time. When a reload is finished, then the editors are triggered to query again.
Activity
Pulled. Leaving open the issue until we verify any side-effects.
Mauro Talevi
added a comment - Pulled. Leaving open the issue until we verify any side-effects. Mauro Talevi
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Mauro Talevi [ maurotalevi ] |
Mauro Talevi
made changes -
| Status | Open [ 1 ] | In Progress [ 3 ] |
@maurotalevi should we create a new issue for the following pr: https://github.com/jbehave/jbehave-eclipse/pull/12 or can this be merged in along side this issue... the root issue I believe both prs were trying to solve are the performance of the eclipse plugin...
Paul Barton
added a comment - - edited @maurotalevi should we create a new issue for the following pr: https://github.com/jbehave/jbehave-eclipse/pull/12 or can this be merged in along side this issue... the root issue I believe both prs were trying to solve are the performance of the eclipse plugin... Yes, please create a new issue.
Mauro Talevi
added a comment - Yes, please create a new issue. Mauro Talevi
made changes -
| Summary | Cache reload asynchronous, Pull request | Asynchronous cache reload |
Mauro Talevi
made changes -
| Resolution | Fixed [ 1 ] | |
| Status | In Progress [ 3 ] | Resolved [ 5 ] |
Additional info:
For each reload request, a new, empty cache is created. As far as I could gather it, the cache has some sort of delta mechanism which would avoid reloading of unchanged data; This delta check is thus now useless, but might help for future extensions where the current cache is cloned to serve as basis for a new reload.
Field experience will show whether this becomes necessary.
Also, from the description of issue #1 about a slow editor with large files I'm not sure whether this fix applies here; It could be that iterating through the step candidates themselves for highlighting might be a second slow-down. But first things first, let's see if this change has any positive effect here.
I based my changes on the recent merge from upstream yesterday, it should apply seamless. (Hoping my newly acquired git skills did the trick
)