We're aware that 7.5 has some performance issues, particularly with larger repos and projects, and we're currently working on the next version. The fixes we're planning are entirely focused on performance, across the entire range of functions.
We're also doing our own benchmark testing, to make sure we can get performance improvements comparable to 7.0.x versions.
We'll be looking at getting some people to try an early release version, is this something you might be interested in?
I am interested in testing performance betas as well, but I'm not sure that 7.0.x is the best benchmark, as I noticed performance degradation from the 6.x series, especially in memory consumption.
I too would be happy to test performance releases. I've got several working copies ranging from roughly 2MB, to an on disk total space of >5GB. If that doesn't tax SmartSVN, I do not know what will.
Great, thanks guys.
I'll give you a nudge as soon as we've got a preview release available.
[QUOTE=Mand;132431]Great, thanks guys.[/QUOTE]
Well thank you for considering such. I am looking forward to it...
I would also like to voice my displeasure with how noticeably slower 7.5.x is in general. One of the reason SmartSVN was so good before is it was pretty snappy. Now it feels like a dog at times
Where are you guys at on this? It takes me ~10 minutes to open my project with 5 sandboxes in it on my system w/ SMARTSVN_MAX_HEAP_SIZE=2048m and "fs.inotify.max_user_watches = 40000" in my /etc/sysctl.conf.
Out of curiousity, are you guys inotifying on every file-system node in the sandbox, including ignored files in ignored directories? If so, check this out in my typical sandbox (of which I'd like to keep 5-10 in a project):
The number of file-system nodes [B]that subversion cares about[/B] in a sandbox:
$ svn ls -R . | wc -l
The [B]total[/B] number of file-system nodes that in a sandbox:
$ find . | wc -l
So if you're maintaining any information about ignored files, [B]especially in ignored directories[/B], please don't do that! Or at least give us a preference to tell you not to.
I have another update for those on this thread:
I mentioned to a co-worker my horrible start-up performance and he said he didn't have that problem at all. So I looked into all the differences, and it looks to me like the bulk of my performance issues are due to using Oracle Java 7 on my Ubuntu 10.04 LTS installation. When I switched back to OpenJDK 6, using the update-java-alternatives tool, all my problems went away.
I found it very odd that SmartSVN would perform so much worse on the recommended newer proprietary JRE than it does on the unrecommended older open-source JRE, so I tried out Oracle Java 6 (from [URL="http://www.webupd8.org/2012/01/install-oracle-java-jdk-7-in-ubuntu-via.html"]the lovely webupd8 oracle java ppa[/URL] this time), and it was fast.
So I tried out Oracle Java 7 again (this time from the webupd8 ppa), and it's still fast.
So whatever my problem was seems to have been some kind of java installation problem that has magically gone away. Wierd.
Never mind about that previous post. The problem is Java 7 and its accompanying inotify usage on Linux. I'm going to just switch back to Java 6 (either Oracle or OpenJDK will do), and live without the fancy auto-refreshing behavior that steals so much of my life.
WANdisco, is there anyone out there?
You just announced that 7.6 is "all about performance," and you haven't helped this issue one bit. It's been reported more recently in other threads, too ([url]http://www.wandisco.com/svnforum/threads/60357-SmartSVN-7-5-is-EXTREMELY-slow-compared-to-SmartSVN-7-0[/url], [url]http://www.wandisco.com/svnforum/threads/45694-SmartSVN-very-slow[/url], )
My usage certainly shows that the problem is the combination of 7.5+ and a Java7 installation. It's unusably slow for large projects.
SmartSVN started using the inotify facility in 7.5 & 7.6 to auto-refresh all nodes in the sandbox. Java7 (1.7+) supports inotify, where Java6 (<=1.6.x) doesn't. I ended up downgrading the java used for SmartSVN to 1.6, so that I could get reasonable performance out of SmartSVN.
The problem is that this requires me to manually refresh SmartSVN to see current statuses, making more of a DumbSVN than a smart one.