Script SVNs extremely slow?

fewyn

Administrator
Staff member
Anyone else notice lately some script SVNs being extremely slow lately while updating? Or is it just me? It seems to mostly be the Sourceforge ones I think.
 

Erich

Member
like if you put "update svn"? It's pretty slow for me to update, but I thought that was just my net connection.
 

fewyn

Administrator
Staff member
Yeah it used to be pretty snappy, rest of my net works fine (I can pull down 10mb/s normally) but it seems in the last couple weeks SVN updates are really slow.
 

Erich

Member
Hm, come to think of it, CHiT has been really slow to load on my relay browser, sometimes finally loading after I already went through 4 or 5 chat commands. If SVN is being really slow, then this post in the CHiT thread:

modifyPage includes this section for version checking:
Code:
	//Check for updates (once a day)

--snip--
This means that if chit.checkversion is true, svn_at_head() will be run on every refresh of the charpane (not just once per day as the comment would indicate). This can cause pretty lengthy delays. Is that intended behaviour?

... and your post here seem to explain why I'm experiencing that.
 

xKiv

Active member
I have also been noticing this behavior for a week or two. I assumed it's just sourceforge being sourceforge.
(though I would *never* call it snappy, even when it was "fast" it was a "go do something else for a while" operation with 36 scripts installed, and that was just *checking* for updates, whithout any of the updating itself)
 

xKiv

Active member
Just for comparison though (svn is native "svn, version 1.8.8 (r1568071)", jsvn is "jsvn, version 1.8.7 (r10376_v20141223_2131)" using java svnkit)

checked out a "random" (= grabbed a checkout command from the next thread over) script, then:
Code:
$ time svn update ; time jsvn update
Updating '.':
At revision 20.

real	0m1.347s
user	0m0.016s
sys	0m0.010s
Updating '.':
At revision 20.

real	0m4.578s
user	0m3.105s
sys	0m0.128s
(most of the extra delay happens after jsvn prints "Updating '.':", so it's not just starting java)
 

Crowther

Active member
xKiv, that's interesting. svn is hardly using any CPU, so the minute plus wait is likely all external. jsvn is using a lot of CPU, so clearly it's thinking about something really hard and spending over 3 minutes doing it. The amount of clocktime spent waiting on external resources is about the same for both: 4.578-3.105-.128 = 1.345 ~= 1.347-.016-.010 = 1.321
 

xKiv

Active member
xKiv, that's interesting. svn is hardly using any CPU, so the minute plus wait is likely all external. jsvn is using a lot of CPU, so clearly it's thinking about something really hard and spending over 3 minutes doing it.
That's seconds, not minutes.

The amount of clocktime spent waiting on external resources is about the same for both: 4.578-3.105-.128 = 1.345 ~= 1.347-.016-.010 = 1.321
That's a meaningless number. The process could have slept even without any waiting resources.

Both jsvn and mafia use svnkit, so if jsvn is "thinking about something hard" then maybe so is mafia?

BTW you used the 3 and 4 correctly as seconds here ;)

BTW2: haha, I just got several "connection timeout" errors trying to show this thread (but not other threads?).
 
Last edited:

Crowther

Active member
That's a meaningless number. The process could have slept even without any waiting resources.
You honestly think that's likely? That meaningless comparison is one of the fastest ways to tell if a process is I/O bound or CPU bound. I've literally used it hundreds of times to help other speed up their jobs. The units don't change that although it's good to have them right for the next steps.
 
I finally went looking to see if there was discussion of slow SVN updates here. My bet is a Sourceforge issue - wasn't there some other SF event recently? I guess there's nothing to be done about it.
 
Top