#84 Regression: example 17 painfully slow with -dev xcairo


This severe performance regression occurs due to Hez's revision 10329. Example 17 runs in roughly 10 seconds for revision 10328 but takes 120 seconds (!)
to run for revision 10329. These times were obtained while running example 17 on a local computer, but if you change to an X-terminal (where example 17
is run remotely, but displayed locally) example 17 still takes roughly 10 seconds for 10328, but for 10329, the LAN traffic goes through the roof, and example 17 takes more than 10 minutes (!) to complete.


  • Hezekiah M. Carty

    • status: open --> closed-fixed
  • Hezekiah M. Carty

    Per discussion on the developers list, this issue seems to be fixed with the dirty rectangles xcairo patch added in commit 10862. Closing, but please re-open if the problem persists.

  • Alan W. Irwin

    Alan W. Irwin - 2010-03-14
    • status: closed-fixed --> open-accepted
  • Alan W. Irwin

    Alan W. Irwin - 2010-03-14

    This issue is mostly fixed by the recent changes, but there is still one example (p10 from the special octave examples) which is much slower for xcairo than it is for qtwidget. Here are the timing results for all "p" examples which show this. Note, all dependencies of these targets will built first so these timing results are for execution time only. Furthermore, my impression is these timing differences are dominated by the difference in speed for the p10 example only.

    TEST1 (over a 100Mbs LAN network)

    Built target test_octave_qtwidget

    real 0m20.156s
    user 0m5.264s
    sys 0m0.396s

    Built target test_octave_xcairo

    real 1m6.928s
    user 0m7.120s
    sys 0m0.876s

    ==> factor of 3.4 slowdown for xcairo compared to qtwidget over the network (and a ton of LAN traffic that virtually brought my X-terminal to its knees).

    TEST2 (local on fast machine)

    Built target test_octave_qtwidget

    real 0m18.204s
    user 0m5.288s
    sys 0m0.384s
    Built target test_octave_xcairo

    real 0m30.626s
    user 0m7.432s
    sys 0m0.780s

    ==> factor of 1.7 slowdown for xcairo compared to qtwidget for the case of local X with no network involved.

    If we could isolate this test to just p10, the slowdown ratio would be much higher than these results. So the essential question to my mind is what change is there in style between p10 and example 17 such that the dirty rectangles idea doesn't work very well for the former, but works essentially perfectly for the latter?

  • Hezekiah M. Carty

    My guess is that something in this example redraws the entire plot frequently which defeats the purpose of the dirty rectangles approach. I may be able to add a fall-back on the old and (for most non-remote cases?) slower approach of drawing directly on the X surface. This could be enabled with a command-line option. I think R provides something similar for its plotting system, with a buffered and unbuffered option for its Cairo output.

    I do not have octave installed on my system, and attempting to install it from the package manager attempts to remove several libraries and development packages I depend on (which seems completely absurd...).

    I can try to install Octave from source and compile PLplot against that for testing. How does one run a single octave example?


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks