Announcement

Collapse
No announcement yet.

git difftool slow on Ubuntu 14.04.5

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • kkiyohara
    started a topic git difftool slow on Ubuntu 14.04.5

    git difftool slow on Ubuntu 14.04.5

    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

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

    Leave a comment:


  • Chris
    replied
    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.

    Leave a comment:


  • Chris
    replied
    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?

    Leave a comment:


  • Glen
    replied
    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'

    Leave a comment:


  • Chris
    replied
    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:
    Code:
    #!/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?

    Leave a comment:


  • Glen
    replied
    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.

    Leave a comment:


  • kkiyohara
    replied
    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.

    Leave a comment:


  • Chris
    replied
    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)?

    Leave a comment:


  • kkiyohara
    replied
    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.

    Leave a comment:


  • Aaron
    replied
    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?

    Leave a comment:


  • kkiyohara
    replied
    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.

    Leave a comment:


  • Aaron
    replied
    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.
    Last edited by Aaron; 24-Jan-2017, 04:34 PM.

    Leave a comment:


  • kkiyohara
    replied
    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




    Originally posted by Aaron View Post
    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

    Leave a comment:


  • Aaron
    replied
    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

    Leave a comment:

Working...
X