It's all about the answers!

Ask a question

RTC3 vs. SVN checkout/update - performance comparison


Bernd van Oostrum (21725371) | asked Dec 03 '10, 6:24 p.m.
Hi,

I imported my build sources (= 1500 projects, 15000 files, 15000 folders) into both RTC and SVN. Then first I checked the sources out (= initial checkout --> all sources get exported), secondly I did an update after changing one of the sources (= accept a change on 1 of the sources).

The timings:

RTC initial checkout : 37 min
RTC update 1 entry : 38 min (!!) (delete before loading is NOT checked in the buildengine and RTC indeed updates 1 file)

svn checkout : 39 min
svn update 1 entry : 8 min

I'm wondering why updating takes such a long time for RTC.

11 answers



permanent link
Anthony Kesterton (7.5k7180136) | answered Dec 03 '10, 7:17 p.m.
JAZZ DEVELOPER
Hi,

I imported my build sources (= 1500 projects, 15000 files, 15000 folders) into both RTC and SVN. Then first I checked the sources out (= initial checkout --> all sources get exported), secondly I did an update after changing one of the sources (= accept a change on 1 of the sources).

The timings:

RTC initial checkout : 37 min
RTC update 1 entry : 38 min (!!) (delete before loading is NOT checked in the buildengine and RTC indeed updates 1 file)

svn checkout : 39 min
svn update 1 entry : 8 min

I'm wondering why updating takes such a long time for RTC.


That looks a bit odd - can you tell us more about what you are doing (eg: using the commandline to do an initial checkout, what version of RTC, etc). For your update - do you mean you accepted changes from the stream, or something else.

regards

anthony

permanent link
Bernd van Oostrum (21725371) | answered Dec 04 '10, 2:27 a.m.
Hi,

I imported my build sources (= 1500 projects, 15000 files, 15000 folders) into both RTC and SVN. Then first I checked the sources out (= initial checkout --> all sources get exported), secondly I did an update after changing one of the sources (= accept a change on 1 of the sources).

The timings:

RTC initial checkout : 37 min
RTC update 1 entry : 38 min (!!) (delete before loading is NOT checked in the buildengine and RTC indeed updates 1 file)

svn checkout : 39 min
svn update 1 entry : 8 min

I'm wondering why updating takes such a long time for RTC.


That looks a bit odd - can you tell us more about what you are doing (eg: using the commandline to do an initial checkout, what version of RTC, etc). For your update - do you mean you accepted changes from the stream, or something else.

regards

anthony


I'm using RTC 3.
For checking out I'm using JBE.exe (to which I gave an extra amount of memory because I couldn't believe the timings the first time, I build on a stream), for SVN I did the checkout using TortoiseSVN. However, the used tooling shouldn't matter (scm.exe vs. jbe.exe, TortoiseSVN vs. svn.exe) too much.
For RTC, the timings represent the time of the fetch-activity, for SVN, the time TortoiseSVN needs to perform the checkout/update.

Today (4/12) I built using a repository workspace. Update for 1 change: 41 minutes. While discouraged, building based on a stream seems to be slightly 'faster'.

Regards,
Bernd.

permanent link
Geoffrey Clemm (30.1k33035) | answered Dec 04 '10, 9:08 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The specifics of exactly what your script is doing, and what context it
is running in are important, because that is not expected performance,
so something must be different about what you are doing and what we
normally see.

As a simple example (not suggesting this your case, just an example), if
you have "delete before load" set in the JBE build, then it will delete
all the existing files before loading, which means you would be doing a
recursive delete followed by a full load, which would be expected to
take slightly longer than a full load.

Cheers,
Geoff

On 12/4/2010 2:38 AM, berndyman wrote:
kestertowrote:
Hi,

I imported my build sources (= 1500 projects, 15000 files, 15000
folders) into both RTC and SVN. Then first I checked the sources out
(= initial checkout --> all sources get exported), secondly I did
an update after changing one of the sources (= accept a change on 1
of the sources).

The timings:

RTC initial checkout : 37 min
RTC update 1 entry : 38 min (!!)
(delete before loading is NOT checked in the buildengine and RTC
indeed updates 1 file)

svn checkout : 39 min

svn update 1 entry : 8 min

I'm wondering why updating takes such a long time for RTC.

That looks a bit odd - can you tell us more about what you are doing
(eg: using the commandline to do an initial checkout, what version of
RTC, etc). For your update - do you mean you accepted changes from
the stream, or something else.

regards

anthony



I'm using RTC 3.
For checking out I'm using JBE.exe (to which I gave an extra amount of
memory because I couldn't believe the timings the first time, I build
on a stream), for SVN I did the checkout using TortoiseSVN. However,
the used tooling shouldn't matter (scm.exe vs. jbe.exe, TortoiseSVN
vs. svn.exe) too much.
For RTC, the timings represent the time of the fetch-activity, for
SVN, the time TortoiseSVN needs to perform the checkout/update.

Regards,
Bernd.

permanent link
Bernd van Oostrum (21725371) | answered Dec 06 '10, 3:26 a.m.
Hi Geoff,

As I wrote in the initial description, I unchecked "delete before loading", so JBE is supposed to do an update and it indeed does update only 1 file.

My script is doing nothing; it is empty.

Regards,
Bernd.




The specifics of exactly what your script is doing, and what context it
is running in are important, because that is not expected performance,
so something must be different about what you are doing and what we
normally see.

As a simple example (not suggesting this your case, just an example), if
you have "delete before load" set in the JBE build, then it will delete
all the existing files before loading, which means you would be doing a
recursive delete followed by a full load, which would be expected to
take slightly longer than a full load.

Cheers,
Geoff

On 12/4/2010 2:38 AM, berndyman wrote:
kestertowrote:
Hi,

I imported my build sources (= 1500 projects, 15000 files, 15000
folders) into both RTC and SVN. Then first I checked the sources out
(= initial checkout --> all sources get exported), secondly I did
an update after changing one of the sources (= accept a change on 1
of the sources).

The timings:

RTC initial checkout : 37 min
RTC update 1 entry : 38 min (!!)
(delete before loading is NOT checked in the buildengine and RTC
indeed updates 1 file)

svn checkout : 39 min

svn update 1 entry : 8 min

I'm wondering why updating takes such a long time for RTC.

That looks a bit odd - can you tell us more about what you are doing
(eg: using the commandline to do an initial checkout, what version of
RTC, etc). For your update - do you mean you accepted changes from
the stream, or something else.

regards

anthony



I'm using RTC 3.
For checking out I'm using JBE.exe (to which I gave an extra amount of
memory because I couldn't believe the timings the first time, I build
on a stream), for SVN I did the checkout using TortoiseSVN. However,
the used tooling shouldn't matter (scm.exe vs. jbe.exe, TortoiseSVN
vs. svn.exe) too much.
For RTC, the timings represent the time of the fetch-activity, for
SVN, the time TortoiseSVN needs to perform the checkout/update.

Regards,
Bernd.

permanent link
Geoffrey Clemm (30.1k33035) | answered Dec 06 '10, 11:38 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I'd suggest working with Rational customer support to determine what is
happening in your environment. The update should not be taking this long.

Cheers,
Geoff


On 12/6/2010 3:38 AM, berndyman wrote:
Hi Geoff,

As I wrote in the initial description, I unchecked "delete before
loading", so JBE is supposed to do an update and it indeed does
update only 1 file.

My script is doing nothing; it is empty.

Regards,
Bernd.




gmclemmwrote:
The specifics of exactly what your script is doing, and what context
it
is running in are important, because that is not expected
performance,
so something must be different about what you are doing and what we

normally see.

As a simple example (not suggesting this your case, just an
example), if
you have "delete before load" set in the JBE build, then
it will delete
all the existing files before loading, which means you would be
doing a
recursive delete followed by a full load, which would be expected to

take slightly longer than a full load.

Cheers,
Geoff

On 12/4/2010 2:38 AM, berndyman wrote:
kestertowrote:
Hi,

I imported my build sources (= 1500 projects, 15000 files, 15000
folders) into both RTC and SVN. Then first I checked the sources
out
(= initial checkout --> all sources get exported), secondly I
did
an update after changing one of the sources (= accept a change on 1
of the sources).

The timings:

RTC initial checkout : 37 min
RTC update 1 entry : 38 min (!!)
(delete before loading is NOT checked in the buildengine and RTC
indeed updates 1 file)

svn checkout : 39 min

svn update 1 entry : 8 min

I'm wondering why updating takes such a long time for RTC.

That looks a bit odd - can you tell us more about what you are
doing
(eg: using the commandline to do an initial checkout, what version
of
RTC, etc). For your update - do you mean you accepted changes from
the stream, or something else.

regards

anthony


I'm using RTC 3.
For checking out I'm using JBE.exe (to which I gave an extra amount
of
memory because I couldn't believe the timings the first time, I build
on a stream), for SVN I did the checkout using TortoiseSVN. However,
the used tooling shouldn't matter (scm.exe vs. jbe.exe, TortoiseSVN
vs. svn.exe) too much.
For RTC, the timings represent the time of the fetch-activity, for
SVN, the time TortoiseSVN needs to perform the checkout/update.

Regards,
Bernd.


permanent link
Bernd van Oostrum (21725371) | answered Dec 08 '10, 7:52 a.m.
Hi Geoff,

By reducing the number of components (20), I could bring the timings back to 14m30s for updating one file. Getting closer to an acceptable result... :)

When updating, I get the message my filesystem (Win7, NTFS) does not support symlinks. This makes me wonder if the performance on linux (support of symlinks) could increase the performance more. Do you have any idea about this?

Regards,
Bernd.

permanent link
Geoffrey Clemm (30.1k33035) | answered Dec 08 '10, 11:23 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The lack of support for symlinks on Win7 should not materially change
your load time (posting the error message shouldn't take significantly
different amount of time than just creating the symlink).

But if you have a Linux box available, it would be interesting to run
the load and update, and see how the performance compares.

When you reduced the number of components, was that from some large
number down to 20, or from 20 down to some very small number? Large
numbers of components (say, hundreds) is known to slow down various
build operations. But just 20 components shouldn't be a problem (at
least, as far as I know ... folks on the build team should correct me if
I got that wrong).

Cheers,
Geoff

On 12/8/2010 7:53 AM, berndyman wrote:
Hi Geoff,

By reducing the number of components
(20), I could bring the timings back to
14m30s for updating one file. Getting
closer to an acceptable result... :)

When updating, I get the message my filesystem (Win7, NTFS) does not
support symlinks. This makes me wonder if the performance on linux
(support of symlinks) could increase the performance more. Do you
have any idea about this?

Regards,
Bernd.

permanent link
Bernd van Oostrum (21725371) | answered Dec 09 '10, 3:06 a.m.
I reduced the number of components from a larger amount down to 20. I agree the amount was way too big...
However, I'm not sure if this is related to build-operations as I timed the load-time, which should be comparable (equal?) to "scm load".

I'll give you an update as soon as I've time to run this on a linux box.

Regards,
Bernd.

The lack of support for symlinks on Win7 should not materially change
your load time (posting the error message shouldn't take significantly
different amount of time than just creating the symlink).

But if you have a Linux box available, it would be interesting to run
the load and update, and see how the performance compares.

When you reduced the number of components, was that from some large
number down to 20, or from 20 down to some very small number? Large
numbers of components (say, hundreds) is known to slow down various
build operations. But just 20 components shouldn't be a problem (at
least, as far as I know ... folks on the build team should correct me if
I got that wrong).

Cheers,
Geoff

On 12/8/2010 7:53 AM, berndyman wrote:
Hi Geoff,

By reducing the number of components
(20), I could bring the timings back to
14m30s for updating one file. Getting
closer to an acceptable result... :)

When updating, I get the message my filesystem (Win7, NTFS) does not
support symlinks. This makes me wonder if the performance on linux
(support of symlinks) could increase the performance more. Do you
have any idea about this?

Regards,
Bernd.

permanent link
Nick Edgar (6.5k711) | answered Dec 09 '10, 9:08 a.m.
JAZZ DEVELOPER
That's correct. The symlinks library should not make any difference, and the build load time should be comparable to scm load (either via the Eclipse client or SCM CLI).

Bernd, I thought we had already established in your earlier PMR that there were known scalability issues when there were (a) many components, and/or (b) components with very many files. The SCM load does a 'merge load', not just an incremental load of the files affected by the new change sets, so it needs to fetch the full tree of files (names + metadata, including content hash, but not content), then determine which content needs to be fetched by comparing against the local SCM metadata. I believe it's the computing and fetching of that file tree that's taking the time, not the actual transferring of content.

You can get a better feel for where the time is going by trying the load from the Eclipse client with Metronome enabled (see 'Metronome Tool' at http://jazz.net/library/article/503).

permanent link
Bernd van Oostrum (21725371) | answered Dec 09 '10, 10:33 a.m.
You're right Nick, when I was doing the initial tests on RTC 3 I just reloaded all in the same way as I did in RTC 2.0.0.2, for which we opened the PMR. I realized this issue too late. Sorry for that!

Your answer


Register or to post your answer.