#1597 ProjectViewer is slow in vcs state repainting
Hi, here is the context
jEdit 5.0 trunk
ProjectViewer 3.4.4
SVNPlugin 1.6.1
I have a project that is opened, jEdit with all it's plugins.
In the project tree, a folder is opened (any folder)
When I'm clicking on the - to close it, it takes a few seconds (about 2 seconds).
That is not very important, that's why the priority is low but I think that it is too much.
In my opinion the folder should be closed immediately, and if there are some tasks that must be done, it should be done in background if it is possible.
I debugged and found that it is the svn getStatus() method that is slow (that's normal since the svn of sourceforge is slow).
97,3% - 2335 ms - 1 inv. java.awt.EventDispatchThread.run
89,1% - 2140 ms - 1 inv. java.awt.event.InvocationEvent.dispatch [exceptional run, recorded for "All states"]
88,8% - 2131 ms - 53 inv. projectviewer.vpt.VPTCellRenderer.paintComponent
88,0% - 2112 ms - 53 inv. projectviewer.vpt.IconComposer.composeIcon
87,7% - 2105 ms - 53 inv. ise.plugin.svn.pv.VersionControlState.getNodeState
87,7% - 2105 ms - 53 inv. ise.plugin.svn.pv.VersionControlState.getNodeState
87,4% - 2099 ms - 31 inv. ise.plugin.svn.pv.VersionControlState.getStatus
87,4% - 2097 ms - 31 inv. ise.plugin.svn.command.Status.getStatus
I've noticed that too and have done some work on the svn plugin side to speed things up. I'm trying to find time to get a release ready for the svn plugin, but still want to fix a couple of other issues. Jarek, if you want, you can assign this one to me since I think the issue is in the svn plugin rather than pv.
Dale, if you are able to speed it up, please do. However the manner PV checks its files' state is not optimal. Issuing vcs_getStatus with every icon repaint should be changed, so better don't close this bug entry until it is optimized in pv. I don't expect to work on it soon.
I agree with the part about PV checking file state. I went through that code a while back when trying to make svn plugin faster. I'll attach a patch if I figure out a better way.
Matthieu, how did you produce that list of times for the method calls?
Patch for performance improvements.
Jarek, would you review the attached patch? It provides a pretty good improvement in the IconComposer class by doing a rewrite of the image compositing code to eliminate PixelGrabber (way slow) and adds a cache for already composed icons.
Dale. Marcelo keeps line lengths within 80. The longer lines are by ensonic. Please break them if possible. Then commit directly. I think your idea is good and code is simplified now, although it doesn't address the main issue here.
It's better to post patches as separate tracker entries. Otherwise if a discussion is needed regarding the patch only, it would obscure the discussion about the reported problem. And here the problem is still open. With repainting of the tree many diffs are run. So I think the patch won't decrease the 2 seconds time.
Matthieu please post your reply (if any) about profiling to jedit-devel. I'll also be interested.
Hi, sorry for the late response, I used JProfiler :
I opened jEdit and project viewer, there was a folder that was on SVN and I know that it is slow to close it. So I started CPU profiling, closed the folder and stopped CPU profiling when it was done.
After some more profiling, it looks like the real culprit is in the VPTCellRenderer. After working on that plus the IconComposer patch, I now get results like this, which I think are pretty good:
5.4% - 355 ms - 1,062 inv. projectviewer.vpt.VPTCellRenderer.getTreeCellRendererComponent
3.7% - 244 ms - 1,062 inv. projectviewer.vpt.VPTCellRenderer.getIcon
3.1% - 202 ms - 1,062 inv. projectviewer.vpt.IconComposer.composeIcon
0.8% - 50,571 µs - 1,062 inv. ise.plugin.svn.pv.VersionControlState.getNodeState
0.7% - 46,527 µs - 1,062 inv. projectviewer.vpt.IconComposer.composeIcons
0.6% - 36,107 µs - 726 inv. projectviewer.vpt.VPTFile.getFile
0.4% - 23,684 µs - 726 inv. projectviewer.config.ProjectViewerConfig.isErrorListAvailable
0.2% - 15,575 µs - 726 inv. projectviewer.vpt.IconComposer.getFileState
0.1% - 5,476 µs - 726 inv. projectviewer.vpt.IconComposer$Helper.getMessageState
0.1% - 5,146 µs - 1,062 inv. projectviewer.vpt.VPTNode.isFile
0.0% - 1,621 µs - 1,452 inv. projectviewer.vpt.VPTFile.getURL
0.0% - 1,475 µs - 1,062 inv. ise.plugin.svn.pv.VersionControlState.getIcon
0.0% - 808 µs - 726 inv. projectviewer.config.ProjectViewerConfig.getInstance
One other difference is I'm using a newer version of the SVN plugin, which I expect to get released later this week.
I have some more testing to do, then I'll check in my changes and update this ticket.
I analyzed svn code and it goes like this in libsvn_wc\status.c:
else if (ignore_text_mods
||(dirent
&& info->recorded_size != SVN_INVALID_FILESIZE
&& info->recorded_mod_time != 0
&& info->recorded_size == dirent->filesize
&& info->recorded_mod_time == dirent->mtime))
That is getStatus runs fast if the file sizes and modification times match. No diffs in that case. As it seems to be the most frequent case, I think PV may still check it at the repainting phase.
Matthieu, please do svn revert -R * on your repository. That should reset the filestamps. Would pv run faster after that?
Jarek, there isn't any C code in the svn plugin.
Final changes are checked in. Performance seems quite good to me.