Poor responsivity during compare

[chrisjj]

While comparing large e.g. 200Mb text files, BC responsivity becomes very poor, e.g. BC takes 7sec to respond to a menu bar click. This on a 3.3GHZ P4 2Gb RAM.

Is this normal?

[Aaron]

We have a 3.16 core2 duo, 4 gig of ram system that is still responsive with 500meg files.

You should be able to handle files of that size. How much free memory do you still have available at the time of the comparison? If you hit your page file (which can be hit with a combination of BC3, Virus scanner, background tasks, other applications), then you will notice a large performance hit.

[chrisjj]

Is that a No?

[Aaron]

Chris did some testing in a VM (single core), and it may be less responsive due to your single core processor. Or perhaps because it was a VM running on top of all of his normal operations.

To know if it is normal, we would need other customers to let us know what they see. I do not think we have a single core machine available in the office to test with (but we may have an older machine we can pull out of retirement).

Did you watch your ram usage before and during the compare? Did it fill up and hit your page file? If so, then that is the cause. With 2 gigs of ram, this could easily be the cause. If not, then it may be because you only have a single core processor.

For other users in the forum, do you notice similar slow down during the comparison? What type of processor and how much ram do you have?

[chrisjj]

> I do not think we have a single core machine available
> in the office to test with

If that means you didn't test BC3 on a single core machine... wow.

> Did you watch your ram usage before and during the compare?

No. I was trying to get work done.

> Did it fill up and hit your page file?

The page file is 3Gb max. Surely a 200Mb compare could not fill that??

> If not, then it may be because you only have a single core processor.

Urk. Doesn't BC use multithreading for the compare v. UI??

[DorothyFan1]

I'm seeing more and more of this when it comes to different software programs. Apparently there are some of us...me included who simply can't afford buying a multi core machine right now and we're stuck with the single core models. Years ago they used to be called "top of the line". Times change...but some of us can't afford to splurge on these new systems. We're in a very painful recession cycle and we'd like to save some money for rainy days.

So the catch appears to be that slowdowns in software response times can now be blamed on single core systems. Hmm. I think it may be time for software developers to warn anybody who still uses single core computers that there might be slow response times or whatever when using Beyond Compare 3 because such software is being developed exclusively for multi core models or top of the line systems using Win 7, etc.

But this shouldn't be our fault that we use single core systems. Just my opinion.

[Chris]

ChrisJJ and DorothyFan1,

Aaron was mistaken, we do have single core systems in our office. We do test BC on them. Early on in the development of BC3, our lead developer Craig even tested BC3 on an AMD K6 machine running Windows 98 that we have in our office to make sure it was still responsive on old hardware.

We aren't a very large company. We can't exhaustively test BC3 on every possible hardware combination. Given the resources we have available, we do a good job of supporting old hardware and old versions of Windows. BC3 is compatible with Windows 95. Quite a few vendors larger than us don't support anything older than Windows 2000.

BC3 is responsive on older systems. However, it is a fact that a current generation multi-core machine is significantly faster (at least twice as fast or faster) than a single core machine from 3 or 4 years ago. No matter how hard our developers work at it, if you run BC3 on hardware that is twice as fast as another computer, it will be more responsive.

Anyway, it isn't unexpected behavior to have a several second delay clicking on a menu item in BC3 when the system is under heavy load comparing a pair of 200 MB files.

Most of our developers are using dual core systems with 4 GB of memory. Since we started work on our Linux port we do quite a bit of work with VMWare Workstation, so more capable systems really help with productivity. However, the oldest machine in daily use in our office is a single core Pentium 4 with 1 GB of memory, so we aren't ignoring older single core systems.

[chrisjj]

> we do have single core systems in our office. We do test BC on them.

That's good to hear. Thanks.

> Anyway, it isn't unexpected behavior to have a several second delay
> clicking on a menu item in BC3 when the system is under heavy load
> comparing a pair of 200 MB files.

I hope you'll consider using multi-threading to solve this. Much less advanced apps I use like Mp3tag do so successfully.

[Chris]

Chris,

Mp3tag is probably doing much less intensive work than BC3. BC3 makes heavy use of multi-threading. However, there is a certain point where your system response time will slow down even in a multi-threaded application if system resources such as memory, CPU, and disk are stressed.

[chrisjj]

> BC3 makes heavy use of multi-threading. However, there is a
> certain point where your system response time will slow down
> even in a multi-threaded application

My system response time is fine during this situation e.g. I can instantly ALT-TAB away and any other app is fully responsive. It is just BC's UI that is slugged by BC activity. Which suggests BC multi-threading is not working right, no??

[Zoë]

Golly, I leave for one week and ridiculous statements like "BC doesn't use multi-threading" start popping up...

BC is heavily multi-threaded, and already has separate threads for the foreground and background tasks. What you're seeing is the background thread consuming the majority of the CPU time available, which isn't all that normal, even for a single-threaded CPU, but there are any number of variables that could be introducing the problem.

You should be able to fix it by opening the Tweaks dialog (Ctrl+Shift+T), and adjusting the "Comparison Priority" setting on the "File Views" tab to "Low". That will give the comparison thread less priority so the GUI thread will respond faster. If you have any other processes on your system that use a lot of CPU time that change can keep the comparison from running quickly though, which is why the default is what it is.

[chrisjj]

> What you're seeing is the background thread consuming the majority of
> the CPU time available

As I said, plenty of CPU time is available to other apps' UI - it is just BC's UI that suffers. For example, I start a text compare of two 200Mb files, ALT-TAB to other apps, see that they respond fine, ALT-TAB back to BC... and see it take 12s to repaint its window. Surely that cannot be due to the BC "background thread consuming the majority of the CPU time available".

[Zoë]

Windows gives a priority boost to the application that currently has focus, so even if BC uses 100% of the CPU time when it's active other applications should stay responsive if they're the active application. Have you tried the tweak I suggested?

[chrisjj]

> Have you tried the tweak I suggested?

I saw no inprovment. I.e.:

1 Launch BC3 on this 3.2GHz P4 2Gb RAM machine
2 On "Saved Sessions" double-click a text compare of two identical 172,627 KB files.
3 Repeatedly ALT+TAB from/to BC3

Expected: BC3 repaints promptly
Observed: BC3 repaints promptly until about 30s has passed, whereupon it stops repainting for 10-20s, ending when the compare activity bar disappears. TM shows BC CPU = 18-23%.

[Zoë]

The other issue it may be is if something in the foreground thread is taking longer than it should. Try changing your display filter to "Show All", turning off "Ignore Unimportant Differences", hiding the thumbnail, and/or turning on the "Lines are independant" option in the File Format dialog. Switching the file format to "<default>" so there isn't a grammar may help too. If any of those fix the issue we can look into what's taking so long.