Re: [Plplot-devel] setlocale

[Hazen Babcock via Plplot-devel]

Hi Phil,

Thank you for the clarification.

If setting the locale is only important for text rendering, using a 
period instead of a comma for example, then maybe it would make more 
sense to guard just the plplot functions that create text? No idea how 
hard it would be to track down all the functions in the library that 
might create text such as tick labels, etc.


Do you know of a unit test that checks that plplot is actually handling 
the locale properly? I wasn't able to find one in my searches.


-Hazen

On 6/14/23 13:33, Phil Rosenberg wrote:

Hi Hazen
Yes, a multiple of around 2.5.

But for my current scenario, that's the difference between a plot taking 
5-10 minutes to render Vs 15-30 minutes. So it's a big difference.


Basically the code spends nearly three quarters of its time changing the 
locale, and only a quarter of its time rendering.


But setting/getting the locale is a a file write/read, so it's wy 
slower than setting a few pixels.


Phil



Sent from Outlook for Android <https://aka.ms/AAb9ysg>

*From:* Hazen Babcock 
*Sent:* Wednesday, June 14, 2023 6:03:03 PM
*To:* Phil Rosenberg ; 
plplot-devel@lists.sourceforge.net 

*Subject:* Re: [Plplot-devel] setlocale

Hi Phil,

Can you clarify a bit about the performance difference? Re-reading what
you wrote below I get the impression that just removing the locale calls
alone would only improve things by about 2.5x? Is that correct?

It sounds like you might have done some profiling, so you might already
have the numbers for memory churn versus the calls to the C locale
function(s)?

best,
-Hazen

On 6/13/23 14:15, Phil Rosenberg wrote:

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 <https://aka.ms/AAb9ysg>>

*From:* Hazen Babcock 
*Sent:* Tuesday, June 13, 2023 1:31:38 PM
*To:* Phil Rosenberg ; 
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 restorin

Re: [Plplot-devel] setlocale

[Phil Rosenberg]

Hi Hazen
Yes, a multiple of around 2.5.

But for my current scenario, that's the difference between a plot taking 5-10 
minutes to render Vs 15-30 minutes. So it's a big difference.

Basically the code spends nearly three quarters of its time changing the 
locale, and only a quarter of its time rendering.

But setting/getting the locale is a a file write/read, so it's wy slower 
than setting a few pixels.

Phil



Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: Hazen Babcock 
Sent: Wednesday, June 14, 2023 6:03:03 PM
To: Phil Rosenberg ; 
plplot-devel@lists.sourceforge.net 
Subject: Re: [Plplot-devel] setlocale


Hi Phil,

Can you clarify a bit about the performance difference? Re-reading what
you wrote below I get the impression that just removing the locale calls
alone would only improve things by about 2.5x? Is that correct?

It sounds like you might have done some profiling, so you might already
have the numbers for memory churn versus the calls to the C locale
function(s)?

best,
-Hazen

On 6/13/23 14:15, Phil Rosenberg wrote:
> 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 
> *Sent:* Tuesday, June 13, 2023 1:31:38 PM
> *To:* Phil Rosenberg ;
> 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 pl

Re: [Plplot-devel] setlocale

[Hazen Babcock via Plplot-devel]

Hi Phil,

Can you clarify a bit about the performance difference? Re-reading what 
you wrote below I get the impression that just removing the locale calls 
alone would only improve things by about 2.5x? Is that correct?


It sounds like you might have done some profiling, so you might already 
have the numbers for memory churn versus the calls to the C locale 
function(s)?


best,
-Hazen

On 6/13/23 14:15, Phil Rosenberg wrote:

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 
*Sent:* Tuesday, June 13, 2023 1:31:38 PM
*To:* Phil Rosenberg ; 
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 
*Sent:* Friday, June 2, 2023 7:47:08 AM
*To:* Haz

Re: [Plplot-devel] setlocale

[Phil Rosenberg]

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 
Sent: Tuesday, June 13, 2023 1:31:38 PM
To: Phil Rosenberg ; 
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 
> *Sent:* Friday, June 2, 2023 7:47:08 AM
> *To:* Hazen Babcock ;
> 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 th

Re: [Plplot-devel] setlocale

[Hazen Babcock via Plplot-devel]

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 
*Sent:* Friday, June 2, 2023 7:47:08 AM
*To:* Hazen Babcock ; 
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 
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

Re: [Plplot-devel] setlocale

[Phil Rosenberg]

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 
Sent: Friday, June 2, 2023 7:47:08 AM
To: Hazen Babcock ; 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 
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/; revis

Re: [Plplot-devel] setlocale

[Arjen Markus]

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 
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 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



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  <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

Re: [Plplot-devel] setlocale

[Hazen Babcock via Plplot-devel]

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 > 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



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 > 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




___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] setlocale

[Phil Rosenberg]

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 
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

Re: [Plplot-devel] setlocale

[Phil Rosenberg]

Just checking again if anyone has any knowledge of this?

As far as I can see, plsave_set_locale and plrestore_locale temporarily set
the LC_NUMERIC locale to "C" during calls to the driver. This sets the
decimal delimiter and the thousands separator and how many digits are
between the thousands separator.

I really can see no use at all to do this for a fill call or most of the
other calls where it is used. Do some drivers convert numbers to text
during their rendering?

I have just tested and I get a 50% speed increase for my shades calls by
removing the locale calls from grfill. This seems pretty significant.

Thanks
Phil

On Mon, 29 May 2023 at 00:38, Phil Rosenberg 
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

[Plplot-devel] setlocale

[Phil Rosenberg]

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