Hi Hazen
I hadn't considered what you say about libraries. Let's rule out option 1.
Yes you are correct that drawing large numbers of lines would probably
have a similar poor performance.
I think the act of checking the locale would be similarly slow. I don't
think it's memory churn that is causing slowness. I think it's because
checking and setting the locale involves checking environment variables
or registry entries. I'm not entirely sure though.
I think if options 1 and 2 are disliked, then option 3 is probably the
best option.
I can set things up so that the local only gets set for the first
fill/line and is reset for the last fill/line.
Does that sound okay?
Phil
Sent from Outlook for Android <https://aka.ms/AAb9ysg>
------------------------------------------------------------------------
*From:* Hazen Babcock <hbabc...@mac.com>
*Sent:* Tuesday, June 13, 2023 1:31:38 PM
*To:* Phil Rosenberg <p.d.rosenb...@gmail.com>;
plplot-devel@lists.sourceforge.net <plplot-devel@lists.sourceforge.net>
*Subject:* Re: [Plplot-devel] setlocale
Hi Phil,
I don't think (1) is a good idea. It seems like this only effects
somewhat extreme plotting situations? Some of the examples also use
plshade() and they don't seem to be particularly slow.
Alan I think was concerned that the libraries that come with a driver
might change the locale. The cairo driver for example has a rather large
library behind it. This library might not change the locale, but it
would be hard to be sure, and this might change as the library changes.
Also it seems that the overhead of setting and restoring the locale
would affect any situation with a complicated plot, perhaps most easily
created using plshades, but if you tried to dray 1M lines you might see
something similar? So perhaps there are some optimizations that could be
made instead? For example we could check if the locale was already "C"
before setting it to "C" and then restoring? We could change
saved_lc_numerical_locale to a static variable (and not free it in
plrestore_locale) to reduce the amount of memory churn? We could add a
compiler flag that makes plsave_set_locale() and plrestore_locale() into
nops for those who are okay with this?
best,
-Hazen
On 6/2/23 05:55, Phil Rosenberg wrote:
Hi Hazen, Arjen
Thanks for the detective work - Alan has used that feature to help me in
the past and I had totally forgotten about it.
I can see Alan's intention here. In the wxWidgets driver I did similar
things with other properties. For example I ensure the device context
pen and brush are always set and reset during calls to the driver. This
is so that if the user draws to the device context between calls, then
plPlot does not cause problems for the user and visa-versa.
Setting and resetting the brush was also an expensive operation, so to
avoid those calls I have added an escape for starting and stopping
plshade. I know that between these escapes there is no need to worry
about setting and restoring the state.
I think there are a few options, from most intrusive to least intrusive.
1. Undo Alan's work and make it the responsibility of the driver to
restore the locale. This is what wxWidgets does with device context brushes.
2. Find where we think the locale might need saving and restoring and
only do it for these calls. I'm not sure I like this, as it makes
responsibility a grey area. Also I just tried 'ack locale' and 'ack
LC_NUMERIC in the src directory and found references only in plargs.c,
plcore.c and plctrl.c. So I don't think any drivers do actually change
the locale.
3. I can add a variable to the PLStream which records when we enter and
leave a plshade call. This can be checked during plfill calls so that
only direct plfill calls save and restore the locale.
My preference is for 1 or 3, does anyone else have a preference or other
thought? 3 is certainly an easier change, but I'm happy to go down
another route if people think it will be an improvement.
Just to give an idea of the overall benefits here. I'm plotting data on
a grid with millions of points. The wxWidgets driver changes I mentioned
above and the removal of the locale save/restore and the changes I
mentioned a few weeks ago with buffer memory, mean that instead of
giving up after plPlot had been rendering for a few hours, the plot is
rendered in under 2 minutes. So that's around two orders of magnitude
speed increase at least.
Phil
------------------------------------------------------------------------
*From:* Arjen Markus <arjen.mar...@deltares.nl>
*Sent:* Friday, June 2, 2023 7:47:08 AM
*To:* Hazen Babcock <hbabc...@mac.com>;
plplot-devel@lists.sourceforge.net <plplot-devel@lists.sourceforge.net>
*Subject:* Re: [Plplot-devel] setlocale
Hi Hazen, Phil,
If the setting and restoring of the locale takes so much time, then
would it be an option to use this only on the plot functions that might
actually be affected by the locale? I have only glanced at the code and
I have no idea how much work it would be. That would preserve the
intended functionality though and get rid of the performance issue.
Regards,
Arjen
-----Original Message-----
From: Hazen Babcock via Plplot-devel <plplot-devel@lists.sourceforge.net>
Sent: Thursday, June 1, 2023 12:57 AM
To: plplot-devel@lists.sourceforge.net
Subject: Re: [Plplot-devel] setlocale
Caution: This message was sent from outside of Deltares. Please do not
click links or open attachments unless you recognize the source of this
email and know the content is safe. Please report all suspicious emails
to "servicedesk-...@deltares.nl" as an attachment.
Github has an interesting feature which lets you browse the code and see
the last commit that touched a particular part of the code. Using that
it looks like saving and restoring the locale was added to the functions
in src/plcore.c by Alan on Sep 7, 2009.
The commit message:
"""
Protect all device driver calls using the (now) reentrant plsave_set_...
...locale
and plrestore_locale. The former saves the fundamental PLplot LC_NUMERIC
locale and then sets the LC_NUMERIC locale to "C" for everything done by
all device drivers. Of course, any library called by a device driver
can also change the locale, but we guard against such changes affecting
the rest of PLplot by using plrestore_locale to restore the fundamental
PLplot LC_NUMERIC locale saved by plsave_set_locale.
N.B. this logic allows the fundamental PLplot LC_NUMERIC locale (except
for the parts like the device drivers and palette file reading that are
protected by the combination of plsave_set_locale and plrestore_locale)
to be any valid locale set by any application or library that calls the
PLplot library. If that locale specifies comma decimal separators
rather than period decimal separators, for example, then the PLplot core
will automatically use those for for specifying axis labels. Those
commas for axis labels are drawn by the PLplot core for the Hershey font
device drivers or just propagate to the unicode device drivers as UCS4
arrays. Thus, in both cases, we get a comma decimal separator for axis
labels (if that is what the fundamental PLplot LC_NUMERIC locale calls
for) independently of the logic of the present commit that sets the
LC_NUMERIC locale to "C" for all device driver code that is executed.
svn path=/trunk/; revision=10383
"""
-Hazen
On 5/31/23 10:56, Phil Rosenberg wrote:
> Sorry, I was wrong in my last email - removing the locale calls from
plP_state as well (used to reset the width after a contour draw within
plshade) I ended up with a 2.5 times speed increase > > Phil > > On
Mon, 29 May 2023 at 00:38, Phil Rosenberg <p.d.rosenb...@gmail.com
<mailto:p.d.rosenb...@gmail.com <mailto:p.d.rosenb...@gmail.com
<mailto:p.d.rosenb...@gmail.com>>>> wrote:
>
> Hi all
> I have been making further optimisations to the wxwidgets backen, as
> I have still been finding it painfully slow for plshade calls.
> It turned out that almost all the time within the backend (>99%) was
> spent selecting pens and brushes and allocating memory for every
> fill within the plshade call. Less that 1% was actually spent within
> the rendering call to wxWidgets. I have made some good improvements
> here.
>
> However, in addition to this, about 50% of the total execution time
> is spent in the setlocale function. This is called before and after
> each polygon fill in the core plplot code.
>
> I wondered if anyone really knows the purpose of these calls?
> Perhaps they are to ensure we have consistent numeric
> representations across regions? If so, then I don't really
> understand why they are needed for polygon fills.
>
> Any thoughts would be welcome
> Phil
>
>
>
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
<https://lists.sourceforge.net/lists/listinfo/plplot-devel>
<https://lists.sourceforge.net/lists/listinfo/plplot-devel
<https://lists.sourceforge.net/lists/listinfo/plplot-devel>>
On 5/31/23 10:56, Phil Rosenberg wrote:
Sorry, I was wrong in my last email - removing the locale calls from
plP_state as well (used to reset the width after a contour draw within
plshade) I ended up with a 2.5 times speed increase
Phil
On Mon, 29 May 2023 at 00:38, Phil Rosenberg <p.d.rosenb...@gmail.com
<mailto:p.d.rosenb...@gmail.com <mailto:p.d.rosenb...@gmail.com
<mailto:p.d.rosenb...@gmail.com>>>> wrote:
Hi all
I have been making further optimisations to the wxwidgets backen, as
I have still been finding it painfully slow for plshade calls.
It turned out that almost all the time within the backend (>99%) was
spent selecting pens and brushes and allocating memory for every
fill within the plshade call. Less that 1% was actually spent within
the rendering call to wxWidgets. I have made some good improvements
here.
However, in addition to this, about 50% of the total execution time
is spent in the setlocale function. This is called before and after
each polygon fill in the core plplot code.
I wondered if anyone really knows the purpose of these calls?
Perhaps they are to ensure we have consistent numeric
representations across regions? If so, then I don't really
understand why they are needed for polygon fills.
Any thoughts would be welcome
Phil
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://list/ <https://list/> <https://list/ <https://list/>>
s.sourceforge.net%2Flists%2Flistinfo%2Fplplot-devel&data=05%7C01%7Carj
en.markus%40deltares.nl%7C44980f7a89174ac2fd6a08db622a585a%7C15f3fe0ed
7124981bc7cfe949af215bb%7C0%7C0%7C638211706231092344%7CUnknown%7CTWFpb
GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
%3D%7C3000%7C%7C%7C&sdata=%2FhX%2F5cUnr67tJIMuLcD1eZgofgKQONlnSgYD4QIb
7gY%3D&reserved=0
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
<https://lists.sourceforge.net/lists/listinfo/plplot-devel>
<https://lists.sourceforge.net/lists/listinfo/plplot-devel
<https://lists.sourceforge.net/lists/listinfo/plplot-devel>>
DISCLAIMER: This message is intended exclusively for the addressee(s)
and may contain confidential and privileged information. If you are not
the intended recipient please notify the sender immediately and destroy
this message. Unauthorized use, disclosure or copying of this message is
strictly prohibited. The foundation 'Stichting Deltares', which has its
seat at Delft, The Netherlands, Commercial Registration Number 41146461,
is not liable in any way whatsoever for consequences and/or damages
resulting from the improper, incomplete and untimely dispatch, receipt
and/or content of this e-mail.
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
<https://lists.sourceforge.net/lists/listinfo/plplot-devel>
<https://lists.sourceforge.net/lists/listinfo/plplot-devel
<https://lists.sourceforge.net/lists/listinfo/plplot-devel>>
