Announcement

Collapse
No announcement yet.

BC3 slow... libqtc rebuild?

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

  • mikko
    started a topic BC3 slow... libqtc rebuild?

    BC3 slow... libqtc rebuild?

    I have read a few other posts about slow startup times of BC3 under recent Linux versions. Running a rather custom brew of Fedora I'm also affected. BC3 needs 5sec to start and compare anything, no matter how small the files are
    I'm using the latest version and tried nearly everything I could figure to find the problem of this slowness.

    One idea still to explore is replacing the included qt3 library with the system one which is a recent built and likely better compatible with the surrounding environment. If I do that, however, BC3 crashes in some fontconfig functions. The remaining option is to make sure libqtc is in sync with the system qt3 library and I've tried finding the code to build it. Problem is, it does not look to be even close to what libqtc used to be in the KDE bindings packages on the net (e.g. kdebindings-3.2.3, latest to still include it). Could you share the build procedure for it and what type of qt3 setup was used (3.3.8?) ?

    Thank you.

    /Mikko

  • mikko
    replied
    Found one clear reason for extra slowness when starting in the home view, the Web Resources Panel. I had it as default open, when I have it closed startup times improve from ~4sec to ~2sec. As this conversation has been going in the wrong thread for some time, I'll open a new thread in BC4 forum

    /M

    Leave a comment:


  • mikko
    replied
    Thanks for the verification. Besides giving you access to the actual machine it's not possible to provide a simple diff with official Fedora 23. I guess I'll have to examine such standard FC23 machine and see if I can spot the reasons... looks to be a Qt font loading/configuration issue...

    I do use the xfce4 window manager and desktop, I have 1.17.4 server, the same 2.22.5 glibc but nearly all software is built for source locally to better integrate with everything.

    /M

    Leave a comment:


  • Aaron
    replied
    I tried setting up a Fedora 23 64bit machine with updates applied, and glibc 2.22.5.fc23, but did not hit any slowdown or difference in startup between launching bcompare and launching bcompare a.txt b.txt

    This may come down do how you've customized your OS. Is there any info you could give to help setup this type of environment? Or is it possible for you to test on a standard Fedora 23 setup?

    Leave a comment:


  • mikko
    replied
    I did that, tried them all with various fonts. The UI style does change, no need for reboot but BC4 behaves the same, much faster to start and do a diff than start the empty home view...

    /M

    Leave a comment:


  • Aaron
    replied
    Hello,

    Try running qtconfig from your command line and switching to a different or default theme. You may also need to reboot to troubleshoot and make certain the theme is applied.

    If qtconfig is not installed, use apt-get install qtconfig-qt4 to install it.

    Leave a comment:


  • mikko
    replied
    Thanks, hopefully he finds a cure for this problem. Meanwhile, I found a BC4 issue when comparing large files and reported that in another thread.
    /M

    Leave a comment:


  • Aaron
    replied
    Thanks for this info dump. I'll pass it on to our Linux developer and see what feedback he has.

    Leave a comment:


  • mikko
    replied
    After experimenting a bit more with BC4 I found the reason of its slow startup and a stack trace is below. Basically, it has to do with computing font metrics and uploading text glyphs to the X server which is quite slow. This only happens if you start BC4 without asking for a diff. When starting with a diff request (two files as arguments on command line) for some reason all this process is skipped and the diff is shown in less than 2 sec.

    writev(6, [{"\212\24O\0A\0@\3\1\0\0\0V\0\0\0\t\0\10\0\1\0\10\ 0\6\0\0\0\0\0\0\0"..., 16240}, {"\0\0\0\0\0\0\0\0005\23\3\23\305\232g\232\377\373 \345\373\364\37
    7\377\377\340\324\337\324\340\375\365\375"..., 440}, {"", 0}], 3) = 16680
    > /usr/lib64/libc-2.22.so(__writev_nocancel+0x24) [0xf86ed]
    > /usr/lib64/libxcb.so.1.1.0(_xcb_conn_wait+0x34b) [0xa57b]
    > /usr/lib64/libxcb.so.1.1.0(_xcb_out_send+0x51) [0xa961]
    > /usr/lib64/libxcb.so.1.1.0(xcb_writev+0x45) [0xa9e5]
    > /usr/lib64/libX11.so.6.3.0(_XSend+0x16e) [0x40c7e]
    > /usr/lib64/libXrender.so.1.3.0(XRenderAddGlyphs+0x1f8) [0x2fd8]
    > /usr/lib64/qt4/libQtGui.so.4.8.7(QFontEngineX11FT::uploadGlyphToS erver(QFontEngineFT::QGlyphSet*, unsigned int, QFontEngineFT::Glyph*, _XGlyphInfo*, int) const+0x54)
    [0x4ea5c4]
    > /usr/lib64/qt4/libQtGui.so.4.8.7(QFontEngineFT::loadGlyph(QFontEn gineFT::QGlyphSet*, unsigned int, QFixed, QFontEngine::GlyphFormat, bool) const+0x989) [0x4f39c9]
    > /usr/lib64/qt4/libQtGui.so.4.8.7(QFontEngineFT::recalcAdvances(QG lyphLayout*, QFlags<QTextEngine::ShaperFlag>) const+0xc3) [0x4f4293]
    > /usr/lib64/qt4/libQtGui.so.4.8.7(hb_getAdvances(HB_Font_*, unsigned int const*, unsigned int, int*, int)+0x111) [0x4231c1]
    > /usr/lib64/qt4/libQtCore.so.4.8.7(HB_HeuristicPosition+0x36) [0xf9026]
    > /usr/lib64/qt4/libQtCore.so.4.8.7(HB_OpenTypePosition+0x2a8) [0xfaea8]
    > /usr/lib64/qt4/libQtCore.so.4.8.7(HB_ShapeItem+0x23) [0xffab3]
    > /usr/lib64/qt4/libQtGui.so.4.8.7(QTextEngine::shapeTextWithHarfbu zz(int) const+0x7c7) [0x453ec7]
    > /usr/lib64/qt4/libQtGui.so.4.8.7(QTextEngine::shapeText(int) const+0x72) [0x454812]
    > /usr/lib64/qt4/libQtGui.so.4.8.7(QTextEngine::shape(int) const+0x95) [0x454b45]
    > /usr/lib64/qt4/libQtGui.so.4.8.7(QTextEngine::width(int, int) const+0x29f) [0x45894f]
    > /usr/lib64/qt4/libQtGui.so.4.8.7(QFontMetrics::width(QString const&, int, int) const+0x1ef) [0x43158f]
    > /usr/lib64/qt4/libQt4Pas.so.5.2.5(QFontMetrics_width+0x6d) [0x14b28d]
    Last edited by mikko; 19-Nov-2015, 03:48 PM.

    Leave a comment:


  • mikko
    replied
    A couple of new traces, maybe of help with your verification. With same execution environment and arguments as before I included a trace with glibc-2.20 which completes in 2.6sec as well as traces of the main thread with stack dumps at futex calls when glibc-2.20, 21 and 22 are used (files u20,u21 and u22). No real difference from 21 to 22 but clearly missing calls compared with version 20.

    While with glibc 2.20 startup is now fine I noticed a new problem, maybe again something to do with my setup only. However, perhaps you can replicate it on your environment. The issue is that once a session is started for comparing 2 files then only one more session can be successfully "appended" to the BC2 UI. When trying to do a 3rd comparison, instead of creating it as before in a new tab, BC3 just crashes... (BC4 works fine for this although compared with BC3 which instantly adds the new session, BC4 takes it's time with constant delay of ~1.5sec)

    Regards,
    /M
    Attached Files

    Leave a comment:


  • mikko
    replied
    After noticing that the recent traces have different futex arguments (and strace looks to have a bug in printing the correct timeout values) I finally found the root problem of the delay: glibc 21 and 22. If using version 20 there's nearly no delay in startup. Still unclear to me why this happens, likely a pthreads/mutex thing... With the code at hand, you have better chances of finding out.
    /M

    Leave a comment:


  • mikko
    replied
    I attached a trace which I run using a user account with minimal configuration overheads. I set the environment variables and called the main executable directly. On my system there-s a hard link to it in the installation directory named 'bcmp' (the program behaves similarly no matter I call it from the original script or as above).

    The (s)trace is attached as well as the files to be compared (a.txt a11.txt)

    Command used was:

    strace -0ffo tr/u bcmp a*

    There's not much overhead compared with a direct run. The moment the diff was shown I pressed Ctrl-Q. It took another ~5sec to terminate.

    I use a slightly modified strace to produce the 0-based timing info on 1st column.

    Regards,
    /M

    p.s.
    A bit of good news is that after upgrading glibc to 2.22 (and perhaps some other changes) BC4 move much quickly, starting now in ~2sec on a 3.4GHz machine. Not sure where the original 15sec delay came from but no time to investigate that as well. Hopefully BC3 gets up to speed as I hope it to be more responsive than version 4 when properly working.

    p.p.s
    I had to rename the upload to a .bcpkg extension as the original tar.xz was not accepted, please change back to expand.
    Attached Files

    Leave a comment:


  • Aaron
    replied
    Something else that might be useful is debugging using gdb. To do se:

    export LD_LIBRARY_PATH=/usr/lib/beyondcompare
    gdb /usr/lib/beyondcompare/BCompare
    run

    (wait for beyond compare to Delay, then hit Ctrl+C)/(Or for other users: if crashing, wait for it to crash)

    thread apply all bt

    This should display a stack trace for all running threads after a delay/crash.

    Please send us whatever output gdb generates and we'll keep trying to figure out what is causing the crash on your system.

    Leave a comment:


  • Aaron
    replied
    Hello,

    If you run
    strace bcompare

    Is the delay long enough to note where in the strace it is delayed? You can post the strace here, or email us at support@scootersoftware.com with a link back to this forum thread for our reference.

    Leave a comment:


  • mikko
    replied
    Well, I figured my hopes for a lightweight 64bit BC3 were delusory... Going the BC4 route makes the problem even worse, 3x slower startup time for 4x bigger binary that does not add any benefit for my use cases.

    With libqtc I wasn't asking for a custom built of it but maybe some help to build my own (if from public sources) or opening its source code to allow for better testing the reasons of the delay. Speaking of this delay, so far all I could see is that BC3's main thread is delayed for 5 sec waiting for a secondary thread which is locked at a timed futex call.

    1.840148 futex(0x8d289f4, FUTEX_WAIT_PRIVATE, 1, {4, 999983620}) = -1 ETIMEDOUT (Connection timed out)

    it happens at 1.84 sec from startup and lasts until 6.84s when the diff is finally shown.
    CPU is nearly idle all of this time...

    A similar issue happens (sometimes) when exiting. A Ctrl-Q press will result in another 5 sec delay until exit.

    /M

    p.s.
    Using an official supported distribution is also impossible as I need an up-to-date system setup ~ Fedora 23. I imagined there are other users in my situation who could also benefit if the root cause of this problem is identified.
    Last edited by mikko; 12-Nov-2015, 03:50 PM.

    Leave a comment:

Working...
X