Community
Participate
Working Groups
1) IMPORTANT: Reload the page first! 2) load minesweeper-require 3) open board.js 4) click on isSwept() 5) Tools->References->Project 6) BUG: It takes around 5 minutes for the references window to open I can make this happen every time on my machine. The project is very small so I don't know why it takes so long.
I am using Chrome.
on orion.eclipse.org, I have never seen slowness like you mentioned. But on beta3 in a target site I can easily reproduce a significant slow-down (not 5 minutes but 30-40 seconds). Its weird, the search finishes pretty fast and the first few refs are successfully passed through Tern, and then it seems to hang for a while while waiting for a read. I haven't figured out why yet.
It sounds as if we are seeing the same thing. I see it in other browsers too (IE). The "5 minute" thing might be a stretch but it is long enough that I go to another window and do something else (because I know it will eventually come back). Repeatable case: We should be able to debug this.
(In reply to Steve Northover from comment #3) > It sounds as if we are seeing the same thing. I see it in other browsers > too (IE). The "5 minute" thing might be a stretch but it is long enough > that I go to another window and do something else (because I know it will > eventually come back). > > Repeatable case: We should be able to debug this. Debugging through this and I found that there is a xhr request being sent out during the refs call that results in a 405 exception being logged. At that point the operation seems to hang until you click in the editor?? Up until the point of the exception, the global search runs fine as does the Tern worker.
Created attachment 257761 [details] workaround This patch probably does not belong in this bug. Only attaching it here because it works around the problem. The search client already loaded the contents of which file in the search result so that it could calculate the start,end offsets of the matches. This patch uses that contents to feed tern instead of loading it again. Which should be a performance improvement too. Mike, does it make sense to send contents in the checkRef request?
(In reply to Silenio Quarti from comment #5) > Created attachment 257761 [details] > workaround > > This patch probably does not belong in this bug. Only attaching it here > because it works around the problem. > > The search client already loaded the contents of which file in the search > result so that it could calculate the start,end offsets of the matches. > > This patch uses that contents to feed tern instead of loading it again. > Which should be a performance improvement too. > > Mike, does it make sense to send contents in the checkRef request? We could definitely send the contents over the wire (we do it for some other of the requests already to avoid calling back to the file client). The only downside is that this could cause mutli-parsing of the same file - if you send the contents along with the request, Tern assumes you want the text updated, which will cause the text to be re-parsed / re-inferred / etc. The fix I am working on for bug 474420 should avoid this problem though.
> We could definitely send the contents over the wire (we do it for some other > of the requests already to avoid calling back to the file client). The only > downside is that this could cause mutli-parsing of the same file - if you > send the contents along with the request, Tern assumes you want the text > updated, which will cause the text to be re-parsed / re-inferred / etc. Doesn't the check in line#38 of refs.js prevent the file from being re-parsed?
I pushed an update that ensures Tern knows the query type *must* have a file. With this fix the code for 'afterLoad' etc is no longer even called. http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=8937c2a90a5069842b055f7c82244f61770c83bb
Do we think the problem is fixed?
I have tried the cases that consistently failed for me and I am no longer able to reproduce them.
(In reply to Silenio Quarti from comment #10) > I have tried the cases that consistently failed for me and I am no longer > able to reproduce them. I would still like to send the text with the request (if would save a call to the file client), but the delays + hanging + etc are fixed.
*** Bug 481959 has been marked as a duplicate of this bug. ***
(In reply to Michael Rennie from comment #11) > (In reply to Silenio Quarti from comment #10) > > I have tried the cases that consistently failed for me and I am no longer > > able to reproduce them. > > I would still like to send the text with the request (if would save a call > to the file client), but the delays + hanging + etc are fixed. Cleaned up the code a bit and added support to send the file contents with the request: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=d1dfd68fb554374c96cd7bd3615d237ea280e39c I'll leave this open until we all have a chance to test.
(In reply to Michael Rennie from comment #13) > I'll leave this open until we all have a chance to test. I found an odd case. Using the steps from bug 481959 on beta3: 1. refresh page 2. invoke Refs > Project 3. let it finish and immediately invoke it again -> hangs there is something going on while resolving the dependencies, the second time you invoke it, Tern thinks it still has 12 outstanding look-ups, but everything was already fetched (there are 45 deps from mocha in this example)
The original problem is fixed for me. Did you want to close this bug and open another one with the steps that make the problem keep happening?
(In reply to Steve Northover from comment #15) > The original problem is fixed for me. Did you want to close this bug and > open another one with the steps that make the problem keep happening? Reopened bug 481959 to track the new hanging. Closing fixed.
