Hi Alan I now see times close to a minute to render both pages of example 2, which is clearly a problem. This is the case with or without -np. I'm not sure why . I will look into it.
Phil On 21 June 2015 at 00:32, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2015-06-20 11:46+0100 Phil Rosenberg wrote: > >> Regarding the speed on Linux.I have a problem which I will describe >> below with my Ubuntu machine, but I have just quickly tested example 3 >> with ssh over the internet connecting to my work CentOS PC. I think >> was the example you used to highlight the problem. On Windows it takes >> about 3 seconds from selecting the wxWidgets driver and pressing enter >> to running the wxViewer and displaying the plot. By comparison the ssh >> over the internet test takes about 10 seconds. 6 of those seconds are >> the time up to the window being initially displayed so they are >> probably the time required to load the executable and for wxWidgets to >> do its initial window setup. This leaves about 4 seconds to transfer >> the data to wxViewer and render. While I agree that this isn't >> brilliant, given all the extra overheads going on with that connection >> I think that is acceptable. What sort of rendering times do you see >> running on an actual Linux machine? > > > Hi Phil: > > I did some timing tests for 5.11.0 for comparison purposes which you > should be able to replicate at least in part (the wxwidgets part) on > your own Linux boxes. In each case after building x00c (one of the > simplest examples), wxwidgets, and other device drivers I ran > > time examples/c/x00c -dev <device> -np > > twice (where I used the second timing result since that tends to be > more reliable with everything required loaded from disk into memory > for that second try) for device = wxwidgets, xcairo, qtwidget, and > xwin. > > The 5.11.0 results when run directly on my principal box (no ssh) were > > wxwidgets: > real 0m0.421s > user 0m0.032s > sys 0m0.036s > > In this (5.11.0) case, the -np option is ignored (I think), but the > wxPLViewer > app seems to disconnect as soon as the page is displayed so > the above time corresponds pretty closely to the time required to > display that one page example. > > xcairo: > real 0m0.163s > user 0m0.016s > sys 0m0.008s > > qtwidget: > real 0m0.323s > user 0m0.060s > sys 0m0.024s > > xwin: > real 0m0.097s > user 0m0.004s > sys 0m0.000s > > If I did the same timing tests from a thin client over ssh, the times > went up by roughly a factor of two, and in no case did the time exceed > 1 second for any of these devices. > > In sum, wxwidgets is a bit slow for > 5.11.0, but still acceptable in comparison with other heavy-duty > interactive devices, and all of those heavy-duty ones are substantially > slower than -dev xwin. > > I also tested the current (2db68f6 Impliment use of nopause in the wxWidgets > driver) master tip in the same way for the direct method of display. > The timing results were similar (as expected) for xcairo, qtwidget, and > xwin. However, the command > > time examples/c/x00c -dev wxwidgets -np > > ended up with the wxPLViewer application frozen with no signs of life > for up to 30 seconds before I gave up and killed it. > > If this test works for you on Windows and also your CentOS box then > you should double check that you are really testing commit 2db68f6 > rather than some local version with added changes, and if you are, > perhaps this issue is due to some wxWidgets version issue? (I am > currently testing the Debian wheezy version 2.8.12.1-12 of WxWidgets.) > > Anyhow, I am anxious to complete the timing test on Linux for master > tip -dev wxwidgets once you can figure out how to unfreeze the > wxPLViewer application for my version of WxWidgets. > > In any case you should be doing similar timing tests yourself between > master tip and 5.11.0 on the Windows and CentOS boxes accessible to > you to make sure there have been no serious timing regressions > introduced during the current release cycle for our wxwidgets device > driver. (The additional timing results I reported above for the xcairo, > qtwidget, and xwin devices are just to give context for these > wxwidgets timing results, and there is no necessity for you to time > any device other than wxwidgets on your various boxes for > 5.11.0 and master tip.) > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ ------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
