git difftool slow on Ubuntu 14.04.5

[kkiyohara]

I'm encountering delays of approximately 10-seconds when diffing multiple files. The first file comes up very quickly. After closing the first file, there is a 10-second delay before the second file diff is shown. This delay occurs for all subsequent files.

Operating System: Ubuntu 14.04.5 LTS
Kernel: Linux 3.13.0-105-generic
Architecture: x86_64

Beyond Compare 4.1.9 for Linux build 21719.

$ git config --global --list
alias.br=branch
alias.ci=commit
alias.co=checkout
alias.st=status
color.ui=auto
core.autocrlf=input
diff.tool=bc3
difftool.bc3.trustexitcode=true
difftool.prompt=false
merge.tool=bc3
mergetool.bc3.trustexitcode=true
mergetool.prompt=false

git version 2.11

[Aaron]

Hello,

Thanks for the report. What kind of delay do you see if you create a test script file for your system that calls sequential bcompare processes, script.sh, with chmod +x:
bcompare test1 test2
bcompare test3 test4
bcompare test5 test6

There's an expected slight delay between closing and re-opening, but I suspect it is Git that is introducing the longer delay for you when calling sequential diffs. Would a --dir-diff work better for your current diff project? Remember to Follow Symbolic Links or use the git --no-symlinks option.

http://stackoverflow.com/questions/3...with-sym-links

[kkiyohara]

I created a script similar to what you requested. The files to be compared are on the local hard drive.

bcompare foo.txt~ foo.txt
bcompare foo.txt~ foo.txt

Running this script shows the same behaviour -- a delay of about 10 seconds. I then modified the script to time each of the individual commands:

time bcompare foo.txt~ foo.txt
time bcompare foo.txt~ foo.txt

I ran the script and attempted to exit the bcompare windows as soon as they became visible. The console logs look like this:

$ sh -x /tmp/bc_test.sh
+ bcompare foo.txt~ foo.txt

real 0m14.017s
user 0m1.033s
sys 0m0.195s
+ bcompare foo.txt~ foo.txt

real 0m13.633s
user 0m1.084s
sys 0m0.177s

Hello,

Thanks for the report. What kind of delay do you see if you create a test script file for your system that calls sequential bcompare processes, script.sh, with chmod +x:
bcompare test1 test2
bcompare test3 test4
bcompare test5 test6

There's an expected slight delay between closing and re-opening, but I suspect it is Git that is introducing the longer delay for you when calling sequential diffs. Would a --dir-diff work better for your current diff project? Remember to Follow Symbolic Links or use the git --no-symlinks option.

http://stackoverflow.com/questions/3...with-sym-links

[Aaron]

Hello,

If you create two sets of very simple, new temp.txt files on your desktop and attempt the diff there, do you see a difference in behavior?

I should clarify that this is closer to the test scenario I ran in my Ubuntu 14 test vm, and I did not see the same delay after the first launch.

[kkiyohara]

Nope -- saw no difference whatsoever.

I did run an strace. It appears that the parent bcompare process is waiting for children to finish. It sits in a wait() for a long time.

[Aaron]

I talked with a developer and we have a couple of hunches.

Customized Fonts: do you have any extra fonts installed? We've seen a similar slowdown when a user had the Infinality modified freetype library installed. If you install qt4-qtconfig then launch with "qtconfig" does reverting to defaults and removing customized fonts help? They may need to be fully uninstalled, as all fonts are still loaded even if they aren't currently set.

Web Panel: on the Home screen, if you close the bottom red pane (which accesses the web) and in the Tools menu -> Options, Tweaks section, disable Check for Updates, then restart your computer. Does this impact the start up time?

[kkiyohara]

I installed qtconfig, but it doesn't show any customized fonts. I also reconfigured bcompare to disable the web panel and the check for updates. But this had no effect on the problem.

I'd like to reiterate that the problem is not with the initial display of differences. When running bcompare from the command line, the side-by-side view comes up very fast and shows the proper differences. When I close the bcompare window, the window closes quickly. But it takes a very long time after the window disappears and when bcompare finally exits.

[Chris]

Is your home directory on an internal disk or is it on a network location? Beyond Compare on Linux stores settings as XML in ~username/.config/bcompare/, it's possible there is a delay writing program settings.

Are you physically present at the Ubuntu Linux machine, or are you accessing it remotely using an X-Window or VNC client?

Are you using the default Unity desktop environment, or are you using an alternate desktop environment (KDE, XFCE, etc)?

[kkiyohara]

My home directory in on a internal SSD.
$ sudo hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 24354 MB in 2.00 seconds = 12203.12 MB/sec
Timing buffered disk reads: 998 MB in 3.00 seconds = 332.22 MB/sec

I'm physically present at the machine when running bcompare. I am using the default Unity desktop environment.

[Glen]

Any update on this thread? I just updated to BC (4.2.3 for Linux build 22587) on Ubuntu 14.04.5 LTS. I am seeing the same ~10 second delay between subsequent file compares-- not the first file, but any following files. I've used BC3 extensively in the past, and did not have this experience. I've moved from Unity to Cinnamon, in case that is relevant.

[Chris]

The original report was for BC 4.1.9. Version 4.2.3 included the fix "Linux: Fixed excessive CPU usage when launching a second comparison from the command line", so it should be better in the current version.

Are you launching diffs from Git?

I just tested a shell script to launch multiple comparisons, after I closed each comparison it took about 3 seconds to launch each additional comparison. Test system was Ubuntu 14.04, Unity desktop, with current updates installed.

Test shell script:

#!/bin/bash
bcompare 1.pas 2.pas 3.pas out.pas
bcompare 1a.pas 2a.pas 3a.pas outa.pas
bcompare 1b.pas 2b.pas 3b.pas outb.pas
bcompare 1c.pas 2c.pas 3c.pas outc.pas

Do you see the same 10 second delay if you launch sequential comparisons from a shell script instead of Git?

[Glen]

My usual work flow is to launch Beyond Compare via "git difftool". But, I'm seeing problems when directly invoking bcompare on local disk files. BC4 launches immediately and shows the diff. I immediately close BC4, and it then sits there for upwards of 10 seconds before the prompt returns. So, it seems like exiting BC4 is slow, which matches what I'm seeing when using git difftool.

~/bin$ time bcompare ragb ragu

real 0m11.066s
user 0m1.108s
sys 0m0.104s
~/bin$ cat ragb
repo forall -c 'echo "Repo ${REPO_PATH}:" ; git branch'
~/bin$ cat ragu
repo forall -c 'echo "Repo ${REPO_PATH}:" ; git $1'

[Chris]

It looks like Cinnamon desktop isn't in the official universe repository for Ubuntu 14.04. So I can try to duplicate your environment on my test system, what repository did you use to add Cinnamon desktop?

[Chris]

Another customer reported this issue and their internal IT department diagnosed it. The performance issue is specific to Linux systems with a very large number of network printers. A fix will be in Beyond Compare 4.2.4; we'll update this forum thread when the fix is available.

[Chris]

Beyond Compare 4.2.4 is now available, it fixes the slow exit issue on Linux reported in this thread.