Bingo! I had totally forgotten about this. When creating the randomGenerator class the constructor of Rand generates an initial seed using system entropy. This is the rand_s() function for windows or by reading from /dev/random on Linux. If system entropy is low then the function must wait for enough entropy to be generated to get a new random number. I have a feeling that the entropy is often generated from mouse movement so if you are using the console mostly or especially if you are running a script that does testing of the many examples then I presume system entropy can be very low. Hence there is a long wait to grab this seed.
I haven't tested this, but I suspect it is rather likely to be the source of the slowdown. Basically what we need here is some way to ensure that two instances of plplot which may be run a short time apart get two different seeds for creating the random name of the memory map. This is to stop name clashes between multiple running instances. Could we rely on all systems having a nanosecond resolution clock? Would a microsecond resolution clock be sufficient to grab a time which would be guaranteed to be different between two running processes? On 19 December 2016 at 12:44, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > Hi Phil and Pedro: > > Please look at the commit message for af41765, and the corresponding > part of the source code (lines 1537-1548 of > drivers/wxwidgets_dev.cpp). I cannot spot anything between those two > uses of the PLPLOT_wxLogDebug macro that would cause the 13-second > pause that shows up on the timestamps (and also I could see that > obvious pause myself when staring at those messages), so the > conclusion I drew in the commit message was it had to be > wxPLDevice::SetupMemoryMap() or wxLogDebug itself (that routine is > called as a result of executing the PLPLOT_wxLogDebug macro) that was > being suspended by something else going on with our wxwidgets code or > the wxwidgets library that has nothing to do with the code in > question. Is that even possible? Could this 13-second "suspension" > be the result of some weird threading issue? > > After reading the above 12 lines of code, will both of you please take the > few > minutes to replicate this same test on some Linux box following the > exact instructions in the above commit message? I know one other > wxwidgets user (Laurent?) has replicated the long pause on Linux, and > I think Phil may have replicated it as well. But this time you will > have detailed timestamped debug messages, and maybe given that > evidence the light will dawn with one of you about what is really > going on here. There sure isn't any such "dawn" here! > > Your totally confused fellow PLplot developer, > > 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 > __________________________ ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/intel _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
