svn-scm
svn-scm copied to clipboard
JohnstonCode
fix: testing files for being repository #661
I've changed onPossibleSvnRepositoryChange to filter out files. This event was triggered with too many files so extension host process used 100% cpu nealry all the time.
I think it doesn't make any sense to call tryOpenRepository on a file.
Still seeing sometimes WARN UNRESPONSIVE extension host, 'johnstoncode.svn-scm, but they appear less frequent. According to profile lambda behind openRepositoriesSorted().find is too heavy for being called many times. both svn.detectExternals and svn.detectIgnored are off.
What do you think?
I will have a look at the profile today and see if there is anything else that can be done.
I am still looking into this. Need a couple of days to think if there is a more efficient way to do this.
global-ignores list is not so big, maybe there are a lot of subfolders with svn:ignore property.
find trunk -type d | grep -v tmp/release | wc -l: 18630.
The most significant performance impact had java extension recompiling code in the background and placing it in global ignored folder EclipseBuild
Can you use this https://github.com/JohnstonCode/svn-scm/suites/622540169/artifacts/4928564 and do a profile for me like the one you did before.
here it is: WARN UNRESPONSIVE extension host, 'johnstoncode.svn-scm' took 90% of 3555.954ms, saved PROFILE here: '/tmp/exthost-75c372.cpuprofile
Can you do another profile with https://github.com/JohnstonCode/svn-scm/suites/622662360/artifacts/4930963 and i will have a look at it tomorrow
Still getting profiles with java extension rebuilding sources exthost-80d6bb.cpuprofile.txt
But overall it seems better
Can i have another profile with this build please https://github.com/JohnstonCode/svn-scm/suites/624652792/artifacts/4976440
Can you give this build a try. Doing some async stuff see if it makes a difference https://github.com/JohnstonCode/svn-scm/suites/625176878/artifacts/4989085
This warning is gone, see no profile warnings anymore. Tried to write it manually (from Show Running Extensions), but chrome perf anaylzer doesn't load it. I think the issue is resolved - event loop is not getting blocked anymore.
BTW why do you think that filtering out only directories is bad idea? (extra IO stat operation?)
Actually extension gone mad, it creates svn process for every file that gets recompiled, from SVN log:
[trunk]$ svn: warning: W155010: The node '/home/yanpas/ssd/work/trunk/EclipseBuild/%javapackage%/javaclass.class' was not found.
[trunk]$ svn: E200009: Could not display info for all targets because some targets don't exist[trunk]$ svn info --xml /home/yanpas/ssd/work/trunk/EclipseBuild/%javapackage%/javaclass.class
[trunk]$ svn: warning: W155010: The node '/home/yanpas/ssd/work/trunk/EclipseBuild/%javapackage%/javaclass.class' was not found.
[trunk]$ svn: E200009: Could not display info for all targets because some targets don't exist[trunk]$ svn info --xml /home/yanpas/ssd/work/trunk/EclipseBuild/%javapackage%/javaclass.class
[trunk]$ svn: warning: W155010: The node '/home/yanpas/ssd/work/trunk/EclipseBuild/%javapackage%/javaclass.class' was not found.
[trunk]$ svn: E200009: Could not display info for all targets because some targets don't exist[trunk]$ svn info --xml /home/yanpas/ssd/work/trunk/EclipseBuild/%javapackage%/javaclass.class
[trunk]$ svn: warning: W155010: The node '/home/yanpas/ssd/work/trunk/EclipseBuild/%javapackage%/javaclass.class' was not found.
[trunk]$ svn: E200009: Could not display info for all targets because some targets don't exist[trunk]$ svn info --xml /home/yanpas/ssd/work/trunk/EclipseBuild/%javapackage%/javaclass.class
[trunk]$ svn: warning: W155010: The node '/home/yanpas/ssd/work/trunk/EclipseBuild/%javapackage%/javaclass.class' was not found.
[trunk]$ svn: E200009: Could not display info for all targets because some targets don't exist[trunk]$ svn info --xml /home/yanpas/ssd/work/trunk/EclipseBuild/%javapackage%/javaclass.class
[trunk]$ svn: warning: W155010: The node '/home/yanpas/ssd/work/trunk/EclipseBuild/%javapackage%/javaclass.class' was not found.
[trunk]$ svn: E200009: Could not display info for all targets because some targets don't exist[trunk]$ svn info --xml /home/yanpas/ssd/work/trunk/EclipseBuild/%javapackage%/javaclass.class
[trunk]$ svn: warning: W155010: The node '/home/yanpas/ssd/work/trunk/EclipseBuild/%javapackage%/javaclass.class' was not found.
[trunk]$ svn: E200009: Could not display info for all targets because some targets don't exist[trunk]$ svn info --xml /home/yanpas/ssd/work/trunk/EclipseBuild/%javapackage%/javaclass.class
[trunk]$ svn: warning: W155010: The node '/home/yanpas/ssd/work/trunk/EclipseBuild/%javapackage%/javaclass.class' was not found.
[trunk]$ svn: E200009: Could not display info for all targets because some targets don't exist[trunk]$ svn info --xml /home/yanpas/ssd/work/trunk/EclipseBuild/%javapackage%/javaclass.class
[trunk]$ svn: warning: W155010: The node '/home/yanpas/ssd/work/trunk/EclipseBuild/%javapackage%/javaclass.class' was not found.
I hid actual classes names, but there are a lot of them.
Now it's UI can't get updated until all svn processes finish. I see no other way than reduce time complexity of this event by some filters
Yeah i was trying to off load everything on the main thread by spinning up CP and getting them to check with svn. The directory check will cause extra IO and shouldn't folder changes trigger this like changes to svn properties? Need to think of a better way to approach this.
shouldn't folder changes trigger this like changes to svn properties
Properties stored in .svn/wc.db, SELECT properties,local_relpath FROM NODES_CURRENT;. When editing prperties temporary files are generated, but they still will be reported as directory event
I was also having trouble with this. Extension seems to fire off tons of svn info commands when modifying files in repository using external tools (e.g SVNTortoise updating working copy)
[trunk]$ svn info --xml c:\Repozytorium\trunk
I've had literally hundreds of those called simultaneously. This even managed to crash our SVN server a few times.
Looking forward to this PR.
Maybe throttling public async updateInfo() in svnRepository.ts would be a good idea?