Closed cckozie closed 4 years ago
Made a PR to improve tC open time - this will not help USFM import time.
@RoyalSix - I've attached in this comment my latest timings. You'll note that the testing for reset selections and alignments is taking about 3 times as long when the edits are performed in the scripture pane as compared to when edits are performed in the check pane of tW or tN. Might we be executing the checking code multiple times when editing in the scripture pane? tC_performance.csv 2.zip
Yes there is definitely some unnecessary code running in the scripture pane
MacBook Pro 2015 (2.7 GHz Intel Core i5) Benchmark testing
Invalidation Checking From Scripture Pane: ~11 secs
Invalidation Checking From Verse Check Pane: ~7.5 secs
editTargetVerse
to when all alerts have been shown indicating reset alignments
Profile-20190731T112148.json.zipSuspected functions with performance issues
validateSelections
took ~2 milliseconds.updateVerseEditStatesAndCheckAlignments
took ~3718 milliseconds.updateVerseEditStatesAndCheckAlignments
has a increase of 185,800% processing time than validateSelectionsupdateVerseEditStatesAndCheckAlignments
calls the following functions:
validateSelections
took 2.9999999969732016 milliseconds.updateTargetVerse
took 348.3000000123866 milliseconds.validateVerse
apis took 13.300000005983748 milliseconds.doBackgroundVerseEditsUpdates
took 2071.9000000099186 milliseconds.updateTargetVerse
and doBackgroundVerseEditsUpdates
took about 3.5x as long when the scripture pane is open.shouldComponentUpdate
on ExpandedScripturePaneModal children
updateTargetVerse
function is still consistently taking about 3 secondsshouldComponentUpdate
on several Container components
Sorry put the comment in a PR issue instead of on here.
Verified on 486c932
Also verified on 70943af
I'm not seeing any noticeable improvements in the latest build, 2.0.0 (2c07d1c) Not seeing any in 2.0.0 (70943af) either. Timings here: tC_performance.csv 3.zip
It appears that the code @RoyalSix did is in the build, but the speed improvements in develop did not translate to performance enhancements in production build. I'll pull this out of the Sprint for now as we need to get to code freeze.
Potential performance improvement in batching localization actions check https://github.com/translationCoreApps/tc-tool/compare/feature-jay-6282?expand=1
Build | Open tC | Import Aliged Matthew | Load tW | Open Scripture tW | Test Resets Scripture tW | Test Resets Check tW | Load wA | Open Scripture wA | Test Resets Scripture wA | Load tN | Open Scripture tN | Test Resets Scripture tN | Test Resets Check tN |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Average of previous 2.0 builds | 21.31 | 52.21 | 15.15 | 2.25 | 22.72 | 8.60 | 15.89 | 1.59 | 13.25 | 13.53 | 1.62 | 12.12 | 4.86 |
2.0.0 (ca6c273) | 18.87 | 60.74 | 13.63 | 3.1 | 22.46 | 12.01 | 17.5 | 2.05 | 7.64 | 12.46 | 2.18 | 10.6 | 4.84 |
Change | -11% | 16% | -10% | 38% | -1% | 40% | 10% | 29% | -42% | -8% | 34% | -13% | 0% |
Observations concerning above timings which were captured on my Mac. On the positive side:
On the negative side:
Based on these findings I am not sure whether to pass or fail the issue.
Notes: time Importing an aligned MAT:
The major part of init of the tools is the validation step in the tool. Not sure why tW takes so long to validate since there are no selections yet on a USFM import.
@RoyalSix - see above, it looks like the major part of the import time is in the project open, and the major part of that time is init of the tools, which primarily runs validation on the whole book. Looks like we will have to optimize the tW validation. So strange that it is slow in tW since on a USFM import there are no verse edits, selections, etc.
Verified project open speedup in translationCore 2.0.0 (d0b5fa1).
In this csv I've split the import process into 3 pieces and added them in columns w, x, and y; Importing Data (elapsed time when "Importing local data" is displayed) Preparing Data (elapsed time when "Preparing project data" is displayed) Loading Data (elapsed time when "Loading project data" is displayed) tC_performance.csv 3.zip
For reference, below is the count of checks existing for the verses edited: Edit performed in tW scripture pane: 1 check in tW, no checks in tN (Mat 24:17) Edit performed in tW check pane: 5 checks in tW, 1 check in tN (Mat 12:10) Edit performed in wA scripture pane: 3 checks in tW, 1 check in tN (Mat 1:4) Edit performed in tN scripture pane: 7 checks in tW, no checks in tN (Mat 1:16) Edit performed in tN check pane: 7 checks in tW, 2 checks in tN (Mat 9:35)
Here are the timings of the 2.0 release build and the latest build on my slow Windows machine. Note that there have been several significant improvements, and one with a significant decrease in performance. tC_performance.csv.zip However, I am still curious as to why the test for resets timings are so different depending on the tool used for editing. Below are comparisons of those times (in seconds) to perform the check for reset selections and invalidated alignments. Edit verse in tW scripture pane: 58.60 Edit verse in tN scripture pane: 28.6 Edit verse in wA scripture pane: 10.94
Edit verse in tW check pane: 39.68 Edit verse in tN check pane: 11.28
2.0.0 (9ef4802) See all timings in attached spreadsheet. There are several significant improvements compared to the 2.0 release. Improvements > 30% highlighted in green, greater than 20% highlighted in blue. It is still taking twice as long to check for resets when editing a verse in the scripture pane of tW as compared to editing it in the scripture pane of wA. tN falls in between the two.
tW scripture pane | 14.88 tN scripture pane | 9.6 wA scripture pane | 7.52 | tW check | 6.64 tN check | 4.24
There have been several deteriorations in performance in moving from 1.1.4 to 2.0. The worst offenders are:
Starting tC (not first time) went from 26 seconds in 1.1.4 to 81 seconds in 2.0.Importing a fully aligned USFM Matthew project went from 37 seconds in 1.1.4 to 59 seconds in 2.0. Timings were made on my fastest machine with the projects folder having been deleted before the tC startup. The only project involved is 41-MAT.usfm.zipAdditional data in tC_performance.csv.zip