You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Harald Hoyer <ha...@t-online.de> on 2009/04/01 08:50:30 UTC
RE: Merge is slow
Update: The source of the performance problem is a directory that contains 10146 files.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1504854
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Re: Merge is slow
Posted by Harald Hoyer <ha...@t-online.de>.
> So, if it takes three minutes, that's 180 seconds for 10,146 files, or
> a merge of about 55 to 60 files per second. I don't think we can
> actually consider that a "performance problem".
Among this huge directory we also have a directory that is "only" large: it contains 1155 files. In this case merge function returns after 4 seconds. So, there seems to be some algoritm that behaves non-linear, otherwise it would take 40 seconds or so. Could someone explain the purpose of such an algorithm? I would not expect a complexity like this here.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1508121
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Merge is slow
Posted by Andy Levy <an...@gmail.com>.
On Wed, Apr 1, 2009 at 10:46, David Weintraub <qa...@gmail.com> wrote:
> On Wed, Apr 1, 2009 at 4:50 AM, Harald Hoyer <ha...@t-online.de> wrote:
>> Update: The source of the performance problem is a directory that contains 10146 files.
>
> So, if it takes three minutes, that's 180 seconds for 10,146 files, or
> a merge of about 55 to 60 files per second. I don't think we can
> actually consider that a "performance problem".
We also don't know what OS or filesystem this is, nor the speed of the
disk. If this is NTFS or FAT32 on a 4200 RPM Windows 2000 laptop,
performance is going to be pretty bad no matter what.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1507772
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Merge is slow
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Apr 1, 2009 at 10:56 AM, Bob Archer <bo...@amsi.com> wrote:
>> Maybe there should be some way of "tuning" the merge tracking on a
>> repository basis. Some people find the merge tracking a godsend.
>> Others really don't need all of the features, and would like the speed
>> of the old 1.4 merging algorithm.
>
> If you specify the revisions to merge on your command line, will it not
> be as performant as 1.4 because it doesn't have to walk the tree and
> look at all the mergeinfo properties?
It still has to look at the properties. Just because you specify a
revision range does not mean that it should merge any revisions within
that range which have already been merged.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1507780
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Merge is slow
Posted by Bob Archer <bo...@amsi.com>.
> Maybe there should be some way of "tuning" the merge tracking on a
> repository basis. Some people find the merge tracking a godsend.
> Others really don't need all of the features, and would like the speed
> of the old 1.4 merging algorithm.
If you specify the revisions to merge on your command line, will it not
be as performant as 1.4 because it doesn't have to walk the tree and
look at all the mergeinfo properties?
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1507745
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Merge is slow
Posted by David Weintraub <qa...@gmail.com>.
On Wed, Apr 1, 2009 at 4:50 AM, Harald Hoyer <ha...@t-online.de> wrote:
> Update: The source of the performance problem is a directory that contains 10146 files.
So, if it takes three minutes, that's 180 seconds for 10,146 files, or
a merge of about 55 to 60 files per second. I don't think we can
actually consider that a "performance problem".
In version 1.4, Subversion didn't have to think about all that
merging. It simply did it rather blindly. Tracking and figuring out
what to merge was your job. Now, Subversion is doing all the thinking
and tracking for you, so I expect it to take a bit more time.
Maybe there should be some way of "tuning" the merge tracking on a
repository basis. Some people find the merge tracking a godsend.
Others really don't need all of the features, and would like the speed
of the old 1.4 merging algorithm.
--
David Weintraub
qazwart@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1507622
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].