1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#265951: more info

    From Lee Revell@1:229/2 to All on Mon Aug 16 00:40:08 2004
    From: [email protected]

    This is actually not a gnome-terminal problem, I was able to reproduce
    the bug with xterm:

    rlrevell@mindpipe:~$ time cat f
    0 256
    8 2
    9 8
    10 28
    11 42
    12 65
    13 61
    14 45
    15 42
    16 35
    17 33
    18 33
    19 32
    20 41
    21 32
    22 45
    23 58
    24 45
    25 45
    26 30
    27 19
    28 6
    29 1
    33 1
    34 1
    35 1
    38 1
    40 1
    42 1
    43 4
    44 3
    46 2
    48 1
    50 1
    51 3
    real 0m3.152s
    user 0m0.002s
    sys 0m0.004s

    [subsequent runs]

    real 0m0.005s
    user 0m0.001s
    sys 0m0.004s

    real 0m3.154s
    user 0m0.001s
    sys 0m0.005s

    real 0m0.005s
    user 0m0.001s
    sys 0m0.004s

    real 0m0.005s
    user 0m0.002s
    sys 0m0.003s

    real 0m3.153s
    user 0m0.001s
    sys 0m0.004s

    So when it's 'fast' it takes .005/.001/.004 with a very slight variance,
    and when it's 'slow' it takes 3.153s real +/- .002s! This makes it
    pretty clear that we either hit one code path or another, much slower
    one.

    Here are the libraries that gnome-terminal and xterm have in common:

    /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
    libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x401c3000)
    libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x401b9000)
    libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401f7000)
    libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x401e9000)
    libXft.so.2 => /usr/lib/libXft.so.2 (0x40028000)
    libXrender.so.1 => /usr/lib/libXrender.so.1 (0x400ef000)
    libc.so.6 => /lib/tls/libc.so.6 (0x402fd000)
    libdl.so.2 => /lib/tls/libdl.so.2 (0x4044a000)
    libexpat.so.1 => /usr/lib/libexpat.so.1 (0x400cf000)
    libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x4003a000)
    libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40061000)
    libncurses.so.5 => /lib/libncurses.so.5 (0x402be000)
    libz.so.1 => /usr/lib/libz.so.1 (0x40439000)

    So the problem is either in one of the above libraries, or with the X
    server itself, or the kernel. For some reason Xrender seems like a good
    place to start looking.

    I am pretty sure this bug has been reported and widely discussed
    elsewhere, with people attributing it to libvte, pango, and
    gnome-terminal itself.

    http://bugzilla.gnome.org/show_bug.cgi?id=122871 http://bugs.gnome.org/show_bug.cgi?id=137864 http://mail.gnome.org/archives/gnome-list/2004-July/msg00095.html

    Lee



    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Lee Revell@1:229/2 to All on Mon Aug 16 01:20:06 2004
    From: [email protected]

    OK, I have confirmed that this also affects rxvt, but to a lesser
    extent. It seems that the 'heavier' the terminal program, the more the behavior is exacerbated.

    Here is a good test to reproduce the problem:

    for f in 1 2 3 4 5 6 7 8 9 10; do (time cat f) 2>> file; done

    So this bug report needs to be moved to another package, but I have mo
    idea which.

    rxvt results:

    real 0m0.006s
    user 0m0.001s
    sys 0m0.004s

    real 0m0.005s
    user 0m0.001s
    sys 0m0.004s

    real 0m0.005s
    user 0m0.001s
    sys 0m0.005s

    real 0m0.005s
    user 0m0.002s
    sys 0m0.003s

    real 0m0.005s
    user 0m0.001s
    sys 0m0.004s

    real 0m0.005s
    user 0m0.001s
    sys 0m0.004s

    real 0m0.005s
    user 0m0.002s
    sys 0m0.003s

    real 0m0.155s <--- slow one
    user 0m0.000s
    sys 0m0.006s

    real 0m0.115s <--- slow one
    user 0m0.001s
    sys 0m0.003s

    real 0m0.011s
    user 0m0.002s
    sys 0m0.002s

    real 0m0.005s
    user 0m0.000s
    sys 0m0.005s

    real 0m0.005s
    user 0m0.003s
    sys 0m0.002s

    real 0m0.005s
    user 0m0.001s
    sys 0m0.004s

    real 0m0.005s
    user 0m0.001s
    sys 0m0.004s

    real 0m0.005s
    user 0m0.002s

    xterm results:

    real 0m0.005s
    user 0m0.001s
    sys 0m0.004s

    real 0m0.005s
    user 0m0.001s
    sys 0m0.004s

    real 0m0.005s
    user 0m0.001s
    sys 0m0.004s

    real 0m0.005s <--- fast
    user 0m0.003s
    sys 0m0.002s

    real 0m2.518s <--- boundary
    user 0m0.000s
    sys 0m0.006s

    real 0m3.349s <--- slow one
    user 0m0.001s
    sys 0m0.006s

    real 0m3.162s <--- slow one
    user 0m0.002s
    sys 0m0.005s

    real 0m3.260s <--- slow one
    user 0m0.001s
    sys 0m0.005s

    real 0m0.006s <--- fast again
    user 0m0.001s
    sys 0m0.004s

    real 0m0.005s
    user 0m0.002s
    sys 0m0.003s

    So while rxvt shows a slowdown of ~60x, for xterm the slowdown is
    ~600x. Using the script above to test also reveals that whatever
    condition causes the slowdown can happen in the middle of a programs
    output.

    Lee



    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)