Re: [Plplot-devel] setlocale

[Hazen B. <hba...@ma...>]

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 waaaay 
> slower than setting a few pixels.
> 
> Phil
> 
> 
> 
> Sent from Outlook for Android <https://aka.ms/AAb9ysg>
> ------------------------------------------------------------------------
> *From:* Hazen Babcock <hba...@ma...>
> *Sent:* Wednesday, June 14, 2023 6:03:03 PM
> *To:* Phil Rosenberg <p.d...@gm...>; 
> plp...@li... <plp...@li...>
> *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 <hba...@ma...>
>> *Sent:* Tuesday, June 13, 2023 1:31:38 PM
>> *To:* Phil Rosenberg <p.d...@gm...>; 
>> plp...@li... <plp...@li...>
>> *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 <Arj...@de...>
>>> *Sent:* Friday, June 2, 2023 7:47:08 AM
>>> *To:* Hazen Babcock <hba...@ma...>; 
>>> plp...@li... <plp...@li...>
>>> *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
>>>