from a typical use case, properties are not big, they are empty.
therefor your concerns are theoretically ok, but in practice not
(yet?) relevant.
and we noticed slow down just by the number of files. we noticed slow
down in disk usage, not memory usage, not processor usage.
doing an svn up on 20.000 files/folders just blocks the disk for 2
minutes.
just deleting a svn working copy blocks the disk cause of the huge
number of files.
and the number is increasing by factor 10 (--> 20.000 files/folders,
200.000 files/folders with the .svn folders).
--- Philip Martin <philip@codematters.co.uk> wrote:
> solo turn <soloturn99@yahoo.com> writes:
>
> > can we make a new pre-1.0 issue for speeding up the client?
> >
> > contents:
> > goal is to reduce the number of files and directories held in
> .svn,
> > cause this does currently not scale and is unusable for checkouts
> to
> > network drives.
> >
> > especially:
> > - put prop-base, props, wcprops into entries file
> > -3 files per managed file
> > -3 folders per managed folder
> > - put dir-wcprops in entries file
> > -1 file per managed folder
> > - put auth in ~/.subversion
> > -1 folder per managed folder
> > -2 files per managed folder
> > - put empty-file, Readme
> > in temporary location or root
> > -2 files per managed folder
> > - put format in entries file or root or temporary
> > location
> > -1 file per managed folder
> > - eliminat "text-base" folder and store the
> > contents directly in .svn
> > -1 folder per managed folder
> >
> > this means in total:
> > -5 folders per managed folder
> > -5 files per managed folder
> > -3 files per manged file
> >
> > root is the most top folder, where a .svn folder exists.
>
> Are you sure that such a change is going to make things faster?
>
> Some possible problems:
>
> - It will mean that all the properties have to be read and parsed
> every time the entries file is read, irrespective of whether they
> are needed. That is likely to slow down the client, not make it
> faster.
>
> - Are you proposing that properties are cached in the access batons
> along with the entries? Properties can be *big*, it's possible
> that
> the memory use would be unacceptable.
>
> - If you don't cache properties then it becomes necessary to parse
> the
> entries file every time you access the properties. This will be
> slower than simply parsing the current properties files.
>
> - It will take longer to write the entries file each time it is
> modified. I suspect that writing the entries file is a real
> scalability problem, I think that it's one of the things that
> causes
> Subversion to slow down when updating a directory with a large
> number of entries. See notes/entries-caching for my (barely
> developed) ideas for solving this.
>
> - The entries file is XML, properties are binary. Will we need to
> encode/decode properties?
>
> I can see there might be a benefit in combining some of the files
> used
> to store properties, but I don't think putting properties in the
> entries file is a good idea. Even combining them into a separate
> file
> is not necessarily a win, it is likely to cause the same
> scalability
> problems that affect the entries file. Such problems may be
> solveable
> for the properties just as for the entries, but simply assuming
> that
> it will be solved is foolish.
>
> --
> Philip Martin
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 5 16:24:29 2003