[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Speed up consecutive operations

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2007-10-22 19:45:55 CEST

He may also be running afoul of svn_sleep_for_timestamps. Using the RA
API would avoid that penalty.

On Mon, 2007-10-22 at 10:42 -0700, Dan Christian wrote:
> What access protocol are you using?
>
> DAV-neon is slowest, SVN is fastest, DAV-serf is in between.
> Encryption slows things down even more.
>
> How big are the queries?
>
> Large file and directories counts will reduce performance.
>
> -Dan C
>
> On 10/22/07, Matthias Junker <matthias.junker@students.unibe.ch> wrote:
> > Hello,
> >
> > i'm working on a client for subversion, which builds a model of a
> > repository in smalltalk. for now i'm just accessing the client api. but
> > the problem is, that i need to call read only commands like ls,diff,etc
> > very often in a row. of course i use the same ctx and pool for all these
> > operations, but they are still very slow (like 1-2s per operation). now
> > my question: would i have to use the repository access layer directly to
> > speed up consecutive operations (by using the same session over and over
> > again?), or is there a way to do this using the client api? Or did i get
> > it all wrong? i would be really glad for any kind of hint, because i
> > just started developing with subversion and it's hard for me to estimate
> > the effort for this.
> >
> > Cheers,
> > Matt
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 22 19:46:14 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.