On 2017-10-03 12:34+0100 Phil Rosenberg wrote:
Can I also just check, in the end what was wrong with the previous comms that I put in place? Didn't we eventually find that the source of the delays was the random number generator for determining the name of the shared memory and nothing to do with the actual comms?
You posted the above question as an add-on to the locate thread, but I am replying to this question in the thread devoted to inefficiencies (see the different subject line) just to keep our discussions of different topics disentangled from each other. That fix you refer to above was a huge Linux success that removed order-of-magnitude inefficiencies with wxwidgets for most of our standard examples. But resolution of that one ineffienciy still left some order-of-magnitude inefficiences for the wxwidgets device for just a small subset of the examples such as example 17 and example 8. Furthermore, the problem with those complex examples is we can only make informed speculation about the cause of the wxwidgets inefficiencies for them so I have decided to make much simpler test examples (see below) which respectively call plline many times and plfill many times to test the speculations that it is many separate graphical line elements and many separate graphical fill elements that are the source of the respective wxwidgets inefficiencies for examples 17 and 8. Simple plline test. This simple example is a variant of standard C example 00 (see attached patch so you can check the efficiency of this simple test yourself) that creates 50000 distinct medium-sized right triangles, and for each of them calls plline. Simple plfill test. This simple example is a variant of standard C example 00 (see attached patch so you can check the efficiency of this simple test yourself) that creates 50000 distinct medium-sized right triangles, and for each of them calls plfill. Here are the timed results (from the launch of the core example to end of rendering (by core example in most cases, but by wxPLViewer in the wxwidgets case). Note the wxwidgets result is for default wxwidgets (new version of that device and IPC3). In all cases I did not use the -np option. Thus, to stop the rendering in a timely manner I had to lean on the enter key with the cursor pointing at the GUI so the GUI had focus and could interpret that key strike as end the GUI. device plline test plfill test default wxwidgets 26 seconds 32 seconds old wxwidgets 18 seconds 30 seconds xcairo 1.4 seconds 2.2 seconds qtwidget 1.5 seconds 1.6 seconds xwin 9.5 seconds 3.4 seconds So from these timing results both plline and plfill are an order-of-magnitude less efficient for -dev wxwidgets (both new and old versions) than for the bulk (everything but the plline case for xwin) of the other interactive devices on Linux. Can we say the same thing for the Windows (MSVC) platform? To establish that important answer, please do the equivalent timing results for these two simple examples on Windows where the table of results you should collect similar to the above should be for the default wxwidgets, old wxwidgets, wingcc, and wingdi devices. Once we have that answer we should be able to figure out further strategies for finding the source of these large plline and plfill -dev wxwidgets inefficiencies. 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 __________________________
plline_example_patch.gz
Description: x00c.c patch for the 50000 plline calls test
plfill_example_patch.gz
Description: x00c.c patch for the 50000 plfill calls test
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
