[HN Gopher] Curious lack of sprintf scaling
       ___________________________________________________________________
        
       Curious lack of sprintf scaling
        
       Author : markdog12
       Score  : 67 points
       Date   : 2022-02-25 21:11 UTC (1 hours ago)
        
 (HTM) web link (aras-p.info)
 (TXT) w3m dump (aras-p.info)
        
       | EdSchouten wrote:
       | I think the only reasonable solution is to completely deprecate
       | functions like setlocale(). Software should just use _l()
       | functions if they want something localised.
       | 
       | Global state considered harmful.
        
         | mort96 wrote:
         | FWIW, the tests show that sprintf_l is no faster than sprintf,
         | if you're passing around the same locale object in different
         | threads. So it can help, but it's not an automatic win unless
         | you make sure that each thread keeps a separate locale object.
        
         | sly010 wrote:
         | Or in this case locale state considered harmful ;)
        
         | worik wrote:
         | Global mutable state.....
        
           | stingraycharles wrote:
           | Well if it wasn't mutable, it wouldn't be state but just a
           | global constant variable. Which is much less harmful.
        
       | addaon wrote:
       | I wonder if the original export code that lead to this
       | investigation was actually correct? It sounds like sprintf() was
       | being called without an explicit locale. This can be fine if
       | Blender does a top-level setlocale(), but can also be subtly and
       | horrible unfine otherwise...
       | 
       | Sounds like there's plenty of opportunity for library-level
       | improvements here (as well as application-level workarounds), but
       | certainly the sprintf_l(..., locale, ...) being slow is the most
       | surprising to me, and likely the easiest to fix.
        
         | markdog12 wrote:
         | You mean like this, from the article?
         | 
         | > Given that this is an Apple operating system, we might know
         | it has a snprintf_l function which takes an explicit locale,
         | and hope that this would make it scale. Just pass NULL which
         | means "use C locale":
         | 
         | And then the chart and discussion following it?
        
           | addaon wrote:
           | Right. My point is that the change from sprintf() to
           | sprintf(..., NULL, ...) is a semantic-modifying change. For
           | the purpose of understanding what's going on, that's fine.
           | For the purpose of optimizing software, that's scary. And
           | even scarier is that it seems somewhat more likely that the
           | version under test is more correct than the version as
           | shipped.
        
             | markdog12 wrote:
             | > Technically, there are no bugs anywhere above - all the
             | functions work correctly
             | 
             | They were all correct. But yeah, scary how primitives can
             | result in such poor performance. FWIW, they ended up using
             | {fmt}: https://developer.blender.org/D13998
        
       | garaetjjte wrote:
       | If you want to read rant about setlocale, highly recommended:
       | https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
        
       | MobiusHorizons wrote:
       | Excuse the lack of context here, I haven't dealt much with
       | locale's in C, and I'm probably showing my ignorance.
       | 
       | Why would you ever mutate a locale object? Is that the common way
       | to change locales in C? Wouldn't it make more sense to have
       | locale objects be roughly immutable? It doesn't seem like they
       | should have any real reason to change very often in a typical
       | use-case. I would think any given person only has a small (1-3 or
       | so) number of locale's they use on any regular basis.
       | 
       | Are locale objects being mutated really common enough that you
       | need a mutex to protect against accidentally rendering something
       | in the wrong locale?
        
         | mort96 wrote:
         | I would guess that there's just nothing in the standard which
         | _prevents_ people from changing the locale. So if you want a
         | conforming implementation, you need your implementation to work
         | if the programmer changed the locale object directly.
        
       | fyrn- wrote:
       | This would really benefit from labeling the y Axis
        
         | formerly_proven wrote:
         | ms for formatting 2 million ints
        
         | AdamH12113 wrote:
         | Agreed. You should always label your axes. In this case, the Y
         | axis is milliseconds on a logarithmic scale.
        
       | formerly_proven wrote:
       | C/C++ locales are a trashfire. The path to enlightenment is to
       | not use them and discard all libraries which think they can get
       | away with calling setlocale (which a few do, but is more or less
       | a given when we're talking about GUIs).
       | 
       | > obviously you should not use sprintf, you should use C++
       | iostreams
       | 
       | Friends don't let friends use iostreams.
        
       ___________________________________________________________________
       (page generated 2022-02-25 23:00 UTC)