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. Phil Phil On 24 June 2015 at 09:24, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: > Hi Alan > As far as the method is concerned I am using shared memory which should > scale very well. The implementation is as a circular buffer, but for most > examples the first circuit is enough. I imagine that the issue is related to > the use of global semaphores to lock that memory and prevent concurrent > access. These are likely to have very different instantiations on Linux and > windows or even different Linux flavours or kernel versions. I may have been > over cautious with their use as finding race condition bugs fan be very > painful. I will look to see if this is the issue and if i can reduce their > use. > > Phil > ________________________________ > From: Alan W. Irwin > Sent: 23/06/2015 17:01 > To: Phil Rosenberg > Cc: PLplot development list > Subject: Re: Status report on remaining issues to be addressed for > theforthcoming 5.11.1 release (wxwidgets issues) > > On 2015-06-22 10:21+0100 Phil Rosenberg wrote: > >> 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. > > Hi Phil: > > I am glad you were able to verify the efficiency problem there since > issues that are only seen on platforms not accessible to the original > developer are a real devil to fix. > > I wonder if the current efficiency regressions are due to the IPC > <https://en.wikipedia.org/wiki/Inter-process_communication> method you > currently use between applications and wxPLViewer not scaling well for > the extra burdens you are placing on that IPC method since 5.11.0? In > particular I would appreciate your comments on whether switching from > your current IPC method (whatever it is) to one of the many other > possibilities in that article might completely solve these efficiency > regressions. > > 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