On 2015-06-24 12:47+0100 Phil Rosenberg wrote: > Hi Alan > > I've done two quick tests. > > The first was to call on valgrind to do some profiling using valgrind > --tool=callgrind examples/c/x03c -dev wxwidgets. This indicated that > the executable spent 75% of its time searching for the wxPLViewer > executable. I must confess that the method I used to hunt it out was > pretty slapdash in that I enumerate the entire build directory. I have > restricted the search to just the utils directory and this is hugely > improved. > > However, I can only assume that the time reported by valgrind doesn't > includes time "doing nothing" for example if I have called sleep and > the OS does something else for a while then I'm not sure valgrind > recognises this as time within the executable. I assume this because > most of the wall clock time of the examples occurs after the viewer > has appeared and functions called after this point are only negligibly > represented by the valgrind results. > > So I did a few more things to work out what was taking so long and the > short story is that most of the time is spent by the console part of > the executable asking the viewer how long the rendered text is. > > Unfortunately there is always going to be some delay when we have the > inter-process communications so this is always going to be a bottle > neck. However I have removed a mutex which was not needed and have > introduced a delay before the viewer reduces its poling frequency. > This has sped things up significantly. The mutex in particular has > helped a lot so probably explains the speed difference between Windows > and Linux. > > I'm not sure there is much else I can do to improve things further.
Hi Phil: I have tested your changes, and I can now at least get the standard examples to finish, but there is still a large efficiency regression compared with what is possible with 5.11.0. Also, my previous timing numbers for both master tip and 5.11.0 were spuriously long for some reason. I suspect I was not actually running directly on our principal box (a 8-year old computer which was high-end when we bought it). But I am doing that now directly from my wife's desktop on that computer as indicated by the "barbara@raven" tag below. In all cases the PLplot software was built using the following compiler options: CXXFLAGS=-O3 -fvisibility=hidden -Wuninitialized CFLAGS=-O3 -fvisibility=hidden -Wuninitialized FFLAGS=-O3 -Wuninitialized 5.11.0: barbara@raven> time examples/c/x00c -dev xcairo -np real 0m0.048s user 0m0.012s sys 0m0.016s barbara@raven> time examples/c/x00c -dev qtwidget -np real 0m0.119s user 0m0.064s sys 0m0.016s barbara@raven> time examples/c/x00c -dev wxwidgets -np real 0m0.222s user 0m0.024s sys 0m0.044s For this case the -np option is a no-op for -dev wxwidgets and x00c relenquishes control of wxPLViewer and finishes the timing when the first (and only page) of this example has been displayed. So it is a pretty realistic timing result that can be compared directly with the equivalent master tip result where the -np option works. But, of course, multipage examples would give spurious timing results for 5.11.0 because the application finishes just as soon as the first page is displayed by wxPLViewer. master tip: barbara@raven> time examples/c/x00c -dev xcairo -np real 0m0.043s user 0m0.016s sys 0m0.008s barbara@raven> time examples/c/x00c -dev qtwidget -np real 0m0.108s user 0m0.060s sys 0m0.016s barbara@raven> time examples/c/x00c -dev wxwidgets -np real 0m3.474s user 0m0.012s sys 0m0.016s So as expected the xcairo and qtwidget efficiency doesn't change that much from 5.11.0 to master tip. However, the efficiency drops by a factor of 16 for -dev wxwidgets and changes wxwidgets timing from a factor of 2-5 slower than the rest for 5.11.0 to a factor of 30-80 slower than the rest. For master tip (where the -np option works for wxwidgets so we can obtain reliable timings even for multipage examples) the slow speed of wxwidgets is also confirmed for x08c: barbara@raven> time examples/c/x08c -dev xcairo -np real 0m1.453s user 0m1.392s sys 0m0.024s barbara@raven> time examples/c/x08c -dev qtwidget -np real 0m0.508s user 0m0.424s sys 0m0.016s barbara@raven> time examples/c/x08c -dev wxwidgets -np real 0m41.480s user 0m0.148s sys 0m0.084s I looked at the top command results during that ~42 seconds, and x08c and wxPLViewer rarely exceeded 10 per cent of cpu usage. In other words they are spending the vast majority of that real time interval waiting for each other. I strongly recommend that your next step should be to confirm the above time results for wxwidgets on your Linux box for both 5.11.0 and master tip to prove they aren't some artifact of my own test environment. Once confirmed, then it seems to me the most promising avenue for you to explore is to try and figure out why both the application and wxPLViewer spend such a large fraction of their time waiting according to the above "top" results. Do you really think such long waits are inevitable with the shared memory IPC method you are currently using (which sounds like it should be quite efficient)? Or is there some small detail of your current IPC method that needs to be tweaked to substantially drop those wait times? 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
