Bug 510909 - Investigate JS performance showing warning/errors
Summary: Investigate JS performance showing warning/errors
Status: RESOLVED WORKSFORME
Alias: None
Product: Orion (Archived)
Classification: ECD
Component: JS Tools (show other bugs)
Version: unspecified   Edit
Hardware: PC Mac OS X
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Curtis Windatt CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2017-01-23 17:12 EST by Silenio Quarti CLA
Modified: 2017-03-08 13:10 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Silenio Quarti CLA 2017-01-23 17:12:03 EST
In orion.eclipse.org,

Load the org.eclipse.org.client repo.
Open these files:  ttyPage.js, modules/orionode/server.js

It takes a long time for the warnings/errors to be displayed. ttyPage.js takes 10s on my machine.
Comment 1 Curtis Windatt CLA 2017-01-25 17:15:16 EST
1) This is not related to the size of the dependency tree.  If you remove the requirements, the delay remains the same and the XHRs for dependent files are relatively fast.

2) No change in the performance is observed using code before the resolver plugin change.  This is likely a separate issue than what Libing reported using Show Problems command.
Comment 2 Curtis Windatt CLA 2017-01-25 17:18:59 EST
3) I copied the file contents to a new project with no running optional Tern plugins and performance was similar.

4) Using electron app I still see a significant delay before linting problems show up.  12 vs 18 sec, so some improvement likely due to the file system.
Comment 3 Curtis Windatt CLA 2017-01-26 14:34:41 EST
For performance improvements related to loading dependent files in Tern, see Bug 511124.  There is very little we can do about how long the tooling plugins take to start up.  There is some time used to configure Tern and load its plugins, but very little (under 1 sec) relative to loading the page.
Comment 4 Steve Northover CLA 2017-01-26 16:20:01 EST
I would like to understand why it wasn't this slow all along (if possible).  We did work to make the tooling load faster and it got slow.  That way, it won't happen again (for the same reason).

Of course, the most important thing is to be fast again.
Comment 5 Curtis Windatt CLA 2017-01-30 16:27:22 EST
(In reply to Steve Northover from comment #4)
> I would like to understand why it wasn't this slow all along (if possible). 
> We did work to make the tooling load faster and it got slow.  That way, it
> won't happen again (for the same reason).
> 
> Of course, the most important thing is to be fast again.

Loading all of our scripts has always been a problem.  When self hosting (so no minified files) or when having network latency issues (as seen in Winnipeg office network previously) the load times can be very painful.  This is not new and it makes our tooling appear slow because the editor shows up but the tooling code in the worker is still loading.

The most significant change affecting linting speed is that our linting is Tern aware and must wait for the dependency tree to be analyzed.  This was severely impacted by by Bug 511124.  Now that it has been fixed this portion of the loading time is super fast.

Silenio, can you give this another try?  I am seeing times under 5 seconds for linting once the editor comes up, but am on a different network than before.
Comment 6 Silenio Quarti CLA 2017-01-30 17:38:54 EST
ttyShell.js is taking 9s in orion.eclipse.org for me. I do not see a big improvement.

server.js is taking 4s.  This one seems to have a noticeable improvement.
Comment 7 Curtis Windatt CLA 2017-01-31 16:27:45 EST
(In reply to Silenio Quarti from comment #6)
> ttyShell.js is taking 9s in orion.eclipse.org for me. I do not see a big
> improvement.

Do you mean ttyPage.js? or tty_shell.js?  They are using two different module systems but both are quite fast for me now.

The time is due to two pieces as I described earlier. Loading the tooling scripts and loading the dependency graph in Tern.  I've already fixed the main issue affecting the dependency graph load and I don't know of a way to speed up the actual file fetch (maybe some kind of batching system?).

If we think this is a real negative experience for the user, we could investigate running the linter without access to Tern right away.  Of course this leads to the warnings in your file changing after a delay or after typing.
Comment 8 Steve Northover CLA 2017-02-01 10:43:10 EST
Where are we on this?  Is performance back to where is was?
Comment 9 Curtis Windatt CLA 2017-02-01 10:55:18 EST
(In reply to Steve Northover from comment #8)
> Where are we on this?  Is performance back to where is was?

I'm moving it to P3, the performance is where it was before, but the delay in starting the tooling can give a bad impression of the tooling.
Comment 10 Curtis Windatt CLA 2017-03-08 13:10:35 EST
I'm closing this as WORKSFORME. We have reduced the network load as much as possible so we are at the mercy of network latency. Even on days where my connection is quite slow, the JS tooling is started within a few seconds of the editor being shown.