Comments on: The results are in, insights into improving NautilusSvn’s performance.

By: skorka

skorka — Mon, 20 Jul 2009 09:56:58 +0000

First of all, i’m new here and want to congratulate you for the initiative, which fills a real gap.
From my personal experience, I’m dealing with a repository of 4GB containing about 25000 files. It is hosted on an external server, and i’m accessing it from the office under windows xp / tortoiseSvn and at home from an ubuntu box.
From the office, the directory access is quasi-immediate. Update/commit take a reasonable time.
From ubuntu, i tried NautilusSvn and it proved unusable in my case. It takes about 10 to 15 minutes to only open 4 nested directories (and sometimes seems to hang).
Good luck and i hope that the performance issue will be in your priorities… in the meanwhile i had to fall back to a simpler tool (eSvn), the use of which is quite fluid.

By: Jeremie Miserez

Jeremie Miserez — Thu, 02 Jul 2009 10:16:32 +0000

Consider my suggestion at comment
http://cobradragon.com/nautilussvn/archives/73/comment-page-1#comment-2467

I made just a minute ago. Basically it’s similar to what Martin Bachmann said, but only for the root folder.

I distinctly recall that TortoiseSVN never checks all the folders recursively, it only updates the emblems on opening the directoy itself. I like the idea that NautilusSVN really does a recursive check and therefore only propose to disable the real-time emblems for the root checkout directory.
Then Nautilus won’t lockup simply because one needed to edit a file outside of the SVN directory but inside the same project directory…

/home/jere/project1/mySVN/ -> update emblems
/home/jere/project1/ -> don’t update emblems, just show a old/cached/general SVN emblem

I think a lot of users would find it acceptable to have slow performance if it’s really restricted to the inside of the svn-directories (“cd”-ing). Merely “ls”-ing the project directory shouldn’t lockup the browser.

By: Bruce van der Kooij

Bruce van der Kooij — Fri, 08 May 2009 13:49:55 +0000

As far as I know, yes it is irrelevant. The problem when you get down to it as I see it mostly has to do with the things mentioned in the File access times and caching post. In the end the best we can do is equal the speed of the svn status command and being written in Python doesn't stop us from achieving this. There's also a relevant discussion on the mailing list you may be interested in. However note that the issue is not related to network latency as Allister indicated.

By: Bruce van der Kooij

Bruce van der Kooij — Fri, 08 May 2009 13:41:21 +0000

Hey Martin, I think I remember our discussion on the mailing list. :-) Both your suggestions are great. So basically a tab in the settings dialog where you have a table to add paths and set a state of “always check”, “only check on click”, “never check”, “never check children” would be sufficient for you?

For bonus points it would be really cool if NautilusSvn were able to automatically detect which working copies you work the most with.

If you can file two separate requests for enhancement I’ll be sure to implement both.

By: Thierry Bothorel

Thierry Bothorel — Fri, 08 May 2009 13:29:58 +0000

Could the use of an interpreted language as python be the bottleneck compared to a compiled program as Tortoise or is this irrelevant?

By: Martin Bachmann

Martin Bachmann — Fri, 08 May 2009 12:22:42 +0000

I’m unfortunately one of the 11%, since we have to deal with a huge projects root folder, containing a lot of projects/repos – which simply is too much for NatilusSVN.

I’ve quickfixed the issue now by excluding that folder (hard-coded), using your hint:

> if (os.path.dirname(realpath(gnomevfs.get_local_path_from_uri(uri)))
> == “/media/Sites”): return False

However, it would be great if

a) exclude-folders would be configurable
b) It would scan/update subfolders of excluded folders in the moment one clicks it
(e.g. /media/Sites/xyz)

I don’t need every subfolder/project folder updated all the time – just the ones I currently work with. This could solve the issue for the unfortunate 11% with too big projects root folders elegantly.

By: Carlos Tasada

Carlos Tasada — Fri, 08 May 2009 07:55:54 +0000

Hi Bruce,

The main issue with the performance, from my point of view, are the continuous freezes in Nautilus when NautilusSVN is updating (mainly after an svn commit or an svn update).

If this issue can be somehow fixed, doesn’t matter if it still takes time, always that you can continue working with the system, the I think it will be good enough for an official 0.12 release.

Just tell me if I can help with anything ;)

By: Steven Rosato

Steven Rosato — Fri, 08 May 2009 03:21:05 +0000

The different suggestions you make about improving, or hiding to the user the performances issues seems a good idea to me. Well I mean, their maybe not the best way, and other user’s comment with other helpful hints could be of help too but I think that the little tricks such as running in background for initial checks or executing the status checks asynchronously could be something to consider, as long as it should be possible to enable/disable that feature in the settings since it’s not everybody that would like it. Personally, I would be pleased with something that would stop nautilus from hanging even if the performances would be the same, the statuses would just periodically refresh while that initial status would do its job. Since I use SVN as a cross-platform and cross-computer file sharing and backuping (yea people can argue on that but I like the way I can just commit when I have deleted old music or such) and thus my directories are enormous, and loading time is a killer on my home.

Anyway, keep up the good work, when I was Googleing for a tortoiseSVN like application for nautilus and stumbled on your application and installed it, I was astonished with the number functionalities implemented for the beta release. Moreover, when I saw that a repo-browser was on the road-map, my choice was clear. Just keep up the good work, and we’ll see with the other comments above what others think :) I give an A+ for NautilusSVN!