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

Reply via email to