SOS 4.1 Client pauses excessively before performing a paint

[Apolon]

The 4.1 SOS Client pauses excessively each time it is selected and must paint a region of the SOS client window. The pause is around 3 seconds - which is very frustrating. I remember a one second pause in V4.0 and earlier. It really should paint the window within hundredths of a second.

During the pause, there does not appear to be any Internet traffic. So it's not attempting to access data from the remote VSS site. There is a lot of local network traffic every time the window needs to paint. My "local" source code is all kept on a Linux Samba server. This approach has been taken so that I can compile on multiple OS platforms using the same checked out code (to confirm portability easily).

It seems that the SOS client paint action clicks off excessive reads on the file system - which is problem for networked drives.

Could you look at this performance issue and improve the responsiveness of the SOS 4.1 client when switching back and forth between other windows?

[lbauer]

Thanks for the report. We'll look into it.

[Apolon]

Thanks for the report. We'll look into it.

Have you had a chance to look at the problem?
i.e. reproduce it or modify SourceOffsite functionality to help performance in that scenario?

[lbauer]

We haven't seen this behavior in-house and haven't had other reports of this. Are you using the Windows or Unix client? What operating system is the client installed on?

What is the CPU utilization when the client takes a long time to repaint? Do you see this slow repaint with any other applications?

[Guest]

We haven't seen this behavior in-house and haven't had other reports of this. Are you using the Windows or Unix client?

Windows client.

What operating system is the client installed on?

Windows XP SP2

What is the CPU utilization when the client takes a long time to repaint?

The CPU usage goes up to around 30% for the period after the SOS client is selected but before the paint actually occurs. See the end of this post for more information.

Do you see this slow repaint with any other applications?

No, the other apps are fine.

The slowdown increases as the number of files in a project/directory increases. A simple test was performed with the Windows XP Task Manager where performance counters were measured before and after the test for a directory with a large number of files. The difference was:
a) Elapsed time was approx 8 seconds
b) CPU time for the sos process increased by 4 seconds.
c) The "I/O Other Bytes" counter increased by ~600,000 i.e. 600K of I/O occurred as a result of the paint. Note that the total size of the directory files was 2.2MB.

I then ran the www.ethereal.com network monitoring application to observe the traffic. It showed SMB protocol interaction with packet types such as QUERY_FILE_INFO, FIND_FIRST2 and Read AndX (with the last type transferring chunks of the source controlled files). The network traffic was very chatty i.e. lots of request/reply interaction where the SOS client presumably has to wait on a response before continuing.

This tends to suggest it's simply an I/O problem where large numbers of request/reply interactions slow down the SOS client paint when the working folder is on a network drive and not a local drive of the Windows XP client PC.

One solution may be, to only perform the individual file checks if the operating system indicates that the contents of the directory has changed since the last file check (via the last modification times of the directory and/or files).

[Apolon]

Hi,

Has there been any progress on the issue in this message thread?
Would you consider implementing paint/performance improvements for situations where the local source code is being kept on a LAN network drive?

Apolon.

[lbauer]

I was able to reproduce paint slowdowns with the working directory on a network drive, and a project in the tree with a file list of over 500 files. This was slow in SOS 3.5.3, but not quite as slow.

I'd like to try to reproduce your situation a little more closely. How many is a "large number" of files?

Is the file status for files in the selected project blank, missing, mixed, etc?

Do you have "use checksums" enabled in the SOS Client under Tools->Options->Files?

[Apolon]

I was able to reproduce paint slowdowns with the working directory on a network drive, and a project in the tree with a file list of over 500 files. This was slow in SOS 3.5.3, but not quite as slow.

I'd like to try to reproduce your situation a little more closely. How many is a "large number" of files?

Displaying a directory of 140 files results in a paint delay of approximately 6 seconds. This is my largest directory file count, but even a delay of (say) 2 seconds for a typical directory slows down the work flow when flipping back and forward through windows.

Is the file status for files in the selected project blank, missing, mixed, etc?

It varies, though mostly blank as I don't edit vast numbers of files at one time.

Do you have "use checksums" enabled in the SOS Client under Tools->Options->Files?

I use checksums by default, but turning checksums off doesn't affect the paint delay time.

[Apolon]

Has there been any progress on this network drive specific performance issue?

Thanks,
Apolon.