[Performance] Switching between / opening files #11094

Open
nethip opened this Issue May 12, 2015 · 9 comments

Projects

None yet

7 participants

@nethip
Contributor
nethip commented May 12, 2015
  • Determine the time it takes to switch between files and also open files
  • Table out the comparative data
  • Analyze the code for figuring out the areas where the performance needs to be improved.

Method used to measure the performance:-

We used iPhone 5S to capture the slo-mo (slow-motion) videos with 120 fps. After capturing the videos, we used Adobe Premier-Pro to calculate the time elapsed to the nearest frames for each of the events being considered(accuracy= 1/120th of a second).

Parameters to consider for testing this.

  1. Test this for small(<500 files), medium(5K files approx) and large(>25K) projects.
  2. Run it on Windows and Mac systems with most likely configurations.
@nethip nethip added this to the Release 1.4 milestone May 12, 2015
@abose abose was assigned by nethip May 12, 2015
@abose abose added the Development label May 13, 2015
@abose
Contributor
abose commented May 17, 2015

System Configuration

Windows iMac
Windows 8.1 Pro 64-bit. Processor: Intel core i7, 3.40 GHz. RAM: 16 GB OS X 10.10.3. Processor: Intel core i7, 3.50 GHz.RAM: 16 GB

Project size used for the comparison - small (265 files, jquery project), medium (5602 files, brackets full src) and large (25852files, brackets src + many extensions) projects.
An iPhone 5S was used to capture slow-motion videos at 120 fps. After capturing the videos, we used Adobe Premiere-Pro to calculate the time elapsed to the nearest frames for each of the events being considered (accuracy= 1/120th of a second).
The testing configuration for all the apps where the default installer feature set for each of the latest versions of the apps as on 5th may 2015.

File open times
For this test, the time to open a single file from a project of the corresponding size was measured averaged over 3 events. For brackets, sublime and VS code, this would mean a double click(start of first click) on a file in the project tree and all events including syntax highlighting complete and the UI render complete. For atom, as single click always opens a file in a tab, the same was the file open criteria.

windows
Brackets atom sublime vs code project size
158ms 208ms 410ms small
175ms 241ms 500ms 410ms medium
175ms 233ms 490ms 320ms large
mac
Brackets atom sublime vs code project size
1060ms 250ms 500ms 625ms small
1270ms 330ms 530ms 540ms medium
950ms 325ms 530ms 470ms large

Observations

  1. Brackets was particularly slow on mac to open a file in any project size (7 times slower than on windows).
  2. Atom showed lower file open times due single click to open a file. In fact sublime always rendered the same file faster on the first click, the extra 250ms from atom to sublime is due to the wait for the second click to open a new tab.
  3. Sublime seems to have higher file open times due to our 'definition' of file open time as all UI render complete. As sublime has an animation on new tabs coming up and this slows down the times; but sublime always rendered the text area swiftly.
    
  4. The redraw of the file tree (react.js) on file open is consuming ~400ms of time on brackets dev builds.
  5. The next highest time (~500ms on brackets dev builds) is consumed by setting the x & y offsets on the code-mirror surface.
  6. The effect of project size on file open times is debatable. So future measures could be restricted just the medium project size.
  7. The file open times that we see in brackets ( debug > Show performance data) closely matches with our observations in win (mac seems anomalous will need to reverify) for the same file.

File switch times
For this test, the time to switch to a single file from a project of the corresponding size was measured averaged over 3 events. This event means a single click on any of the files in the file tree as the starting point and all UI rendered including the syntax coloring as the end point.

windows
Brackets atom sublime vs code project size
220ms 210ms 60ms 210ms small
340ms 270ms 80ms 320ms medium
330ms 250ms 70ms 130ms large
mac
Brackets atom sublime vs code project size
780ms 250ms 80ms 160ms (JSON) 280ms(JS) small
990ms 330ms 60ms 290ms (JS) medium
820ms 325ms 80ms 170ms(JSON) 330ms(JS) large

Observations

  1. Here too brackets was unusually slow on mac compared to all other configuration.
  2. [Optimize] The file tree is redrawn every time a file is switched in brackets taking ~20% time and similar times to render x and y code-mirror offsets.
  3. While analyzing vs code, it got to my attention that switching between JSON and JS files had significantly different switch performance [syntax highlighting?]. Will repeat the same experiment in brackets.
  4. The effect of project size on file switch times is debatable. So future measures could be restricted just the medium project size.
@ryanstewart
Member

@abose did we test this before or after this fix landed? #11043

Or did we just test 1.3?

@abose
Contributor
abose commented May 20, 2015

It was tested on shipping builds (1.3 with extract). The dev builds are usually significantly(in 100xmilli secs) slower as observed while measuring, so I stuck with the release builds.

@abose
Contributor
abose commented May 27, 2015

After profiling file open times, three major areas of optimization candidates are

  1. The shell access for each file read is taking between 100-500ms of time.
  2. React JS event dispatching mechanism is eating lots of time.
  3. code mirror scroll to offset x &y is taking time.
  4. and finally jquery event dispatch is eating some of the active files switch time.
@nethip nethip removed this from the Release 1.4 milestone Jun 25, 2015
@shaneparsons

+1 for a fix for mac.
I almost switched to a different editor the other day because of how long it takes.. I'm sure I'm not the only one too.

@lostlime

+1 for a fix for mac. Switched to Sublime :(

@abose abose referenced this issue Oct 10, 2015
Closed

RESEARCH: Measure performance against other editors #9270

0 of 12 tasks complete
@bryns1
bryns1 commented May 2, 2016

+1 for a fix for a mac. Still crazy slow, again tempting to swap to sublime

@shaneparsons

I ended up switching to sublime, best choice I ever made.

@fullsteamlabs

+1 for macs. It's definitely slowed down for me too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment