[Performance] Find In Files Optimization #11093

Closed
rroshan1 opened this Issue May 12, 2015 · 5 comments

Projects

None yet

4 participants

@rroshan1
Contributor
  • Measure the performance of "Find In Files".
  • Compare the same with other Brackets-like editors.
  • Analyzing the scope for improvements in "Find In Files".
  • Implement the optimizations.
  • Measure the improvements.

Method used to measure the performance:-

We have run multiple FindInFiles searches and 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 in the searches to the nearest frames (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.
  3. Find the performance differences in a repeated search, case-sensitive search and the very first search.
@rroshan1 rroshan1 added this to the Release 1.4 milestone May 12, 2015
@rroshan1 rroshan1 self-assigned this May 12, 2015
@nethip nethip changed the title from Find In Files Optimization to [Performance Story] Find In Files Optimization May 12, 2015
@nethip nethip changed the title from [Performance Story] Find In Files Optimization to [Performance] Find In Files Optimization May 12, 2015
@abose abose added the release-14 label May 13, 2015
@rroshan1
Contributor

Test Machine Configurations

OS Processor RAM
Windows 7 64-bit Intel Xeon E3, 3.40 GHz 16 GB
Mac OS X 10.10.3 Intel Core i7, 2 GHz 8 GB

Limitations

  1. Almost all of the editors are very slow at the first search and perform consistently after the second search. Hence, readings have been noted from second search onwards. (First searches taken into consideration separately).
  2. Sublime Text populates the search results in an editor. There is no indicator to show that the search has ended (unless you keep on scrolling to the end of the page). Hence, we had to go for searches with occurrence in single digits for Sublime.
  3. Visual Studio Code cannot handle searches even for 2100 occurrences approx. Hence, most readings for it are for a subset of the search (around 2000 occurrences) it has done and not the entire search.
  4. For all editors, the time taken for a repeated search or a case-sensitive search does not significantly differ. However, the time taken for a single and multi-word search does differ. We have taken readings for two single-word search and two multi-word search and displayed the average in the table above.

Performance Results

WINDOWS: The average time taken for Find In Files Search:-

EDITORS Small Project Medium Project Large Project
Brackets v1.3 133 msec 741 msec 2767 msec
Atom 350 msec 3941 msec 3950 msec
Visual Studio Code 367 msec 1733 msec 9066 msec
Sublime Text 2 33 msec 1100 msec 5241 msec

MAC: The average time taken for Find In Files Search:-

EDITORS Small Project Medium Project Large Project
Brackets v1.3 250 msec 1408 msec 5241 msec
Atom 433 msec 3158 msec 3125 msec
Visual Studio Code 417 msec 2667 msec 15300 msec
Sublime Text 2 44 msec 1122 msec 14883 msec

Below is a graphical comparison of the performances on Windows and Mac respectively:-
windows findinfiles

mac findinfiles

@abose
Contributor
abose commented May 19, 2015

#11128 PR with incremental update.

@rroshan1
Contributor

Performance scores for Windows and Mac updated in previous comment.

Analysis w.r.t. FindInFiles performance on various editors:-

  1. Brackets performs much better than most editors for most types of project. However, the very first "Find In Files" search takes much longer and also makes Brackets kind of non-responsive. This may be giving a very bad and untrue perception to the users about this performance while other editors populate their search results progressively!!
  2. Sublime is exceptionally well for small projects but quite bad for large projects.
  3. All editors except Atom have considerable differences between medium and large project performances.
  4. While most editors perform similar on Windows and Mac, Brackets performance gets almost halved on Mac environment.
@rroshan1
Contributor

FindInFiles Performance ToDo

  • Make find in files UI non-blocking, when search is performed for the first time after the project is opened. Review this solution #11128 and consider improvements.
  • Currently, Brackets does not update the search results after external updates are made to files (with the file NOT being open in Brackets). Explore the solutions to this issue #10717.
  • Take performance scores on couple of more Mac and Windows systems to verify if Brackets performance on Mac wrt Windows needs attention.

Update:-
Performance scores on Windows and Mac are similar with similar machine configurations. Hence, task 3 is complete and no action needs to be taken.
Adding cards in Waffle for the first two tasks.

@nethip
Contributor
nethip commented May 26, 2015

@rroshan1 Thanks for the breakup. Could you go about creating individual cards for each of the items you have mentioned above?

@prksingh prksingh assigned prksingh and unassigned rroshan1 Jun 25, 2015
@nethip nethip closed this Jul 24, 2015
@abose abose referenced this issue Oct 10, 2015
Closed

RESEARCH: Measure performance against other editors #9270

0 of 12 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment