Hi Alan So I think you should now find the wxPLViewer speed has significantly improved. The item I have dealt with now was that there is a timer at the OS level (initiated by wxWidgets) which sends a message to the viewer which initiates checking for new commands from the console app. At this point I used to check for a single message and return after dealing with it. However it seems that for whatever reason (different OS, different wxWidgets version?) on some systems the minimum time between the timer calls was quite long. This meant that when we were dealing with text which required a lot of small transmissions to the viewer there was a huge overhead. I have now modified things so that on every timer event I check for new transmissions at least 100 times with a 1 millisecond sleep between each. This means that for many small transmissions in a short time we remove most of the overhead.
On my CentOS machine the execution time reported by time x08c -dev wxWidgets -np has dropped from 40s to about 2 s. Note that this only times the console part, not the viewer, but still we have clearly moved to something I would call acceptable. Note that there will always be a significant overhead for the transmission so this will never compete with Cairo, but this is unavoidable because wxWidgets cannot be run in a library without running it as a separate thread and PlPlot isn't thread safe. Note also that when using the wxWidgets driver via the wxWidgets binding (I.e. from within a wxWidgets app) this all becomes irrelevant as the viewer is not used. Anyway I hope this fix closes the issue and you are happy Alan. 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 > __________________________ ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
