Menu
▾
▴
[ jEdit-devel ] [ jedit-Plugin Bugs-3524342 ] ProjectViewer is slow in vcs state repainting
|
From: SourceForge.net <no...@so...> - 2012-05-10 17:12:44
|
Plugin Bugs item #3524342, was opened at 2012-05-07 06:15 Message generated for change (Comment added) made by daleanson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3524342&group_id=588 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Project Viewer Group: None >Status: Closed >Resolution: Fixed Priority: 2 Private: No Submitted By: Matthieu Casanova (kpouer) >Assigned to: Dale Anson (daleanson) Summary: ProjectViewer is slow in vcs state repainting Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Dale Anson (daleanson) Date: 2012-05-10 10:12 Message: Final changes are checked in. Performance seems quite good to me. ---------------------------------------------------------------------- Comment By: Dale Anson (daleanson) Date: 2012-05-09 07:14 Message: Jarek, there isn't any C code in the svn plugin. ---------------------------------------------------------------------- Comment By: Jarek Czekalski (jarekczek) Date: 2012-05-09 02:39 Message: 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? ---------------------------------------------------------------------- Comment By: Dale Anson (daleanson) Date: 2012-05-08 12:54 Message: 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. ---------------------------------------------------------------------- Comment By: Matthieu Casanova (kpouer) Date: 2012-05-08 12:18 Message: 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. ---------------------------------------------------------------------- Comment By: Jarek Czekalski (jarekczek) Date: 2012-05-07 23:52 Message: 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. ---------------------------------------------------------------------- Comment By: Dale Anson (daleanson) Date: 2012-05-07 15:17 Message: 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. ---------------------------------------------------------------------- Comment By: Dale Anson (daleanson) Date: 2012-05-07 13:56 Message: Matthieu, how did you produce that list of times for the method calls? ---------------------------------------------------------------------- Comment By: Dale Anson (daleanson) Date: 2012-05-07 09:39 Message: 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. ---------------------------------------------------------------------- Comment By: Jarek Czekalski (jarekczek) Date: 2012-05-07 09:02 Message: 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. ---------------------------------------------------------------------- Comment By: Dale Anson (daleanson) Date: 2012-05-07 08:12 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3524342&group_id=588 |