Text format (e.g. IridasCube) parsing optimizations

[aras-p]

Primarily driven by a wish to increase performance of parsing .cube files. But the functions that are added or changed are used across parsing of all/most of text based formats.

With these changes, parsing "Khronos PBR Neutral" Iridas .cube file (5.4MB) on Ryzen 5950X / VS2022 Release build: 167ms -> 126ms. Parsing the same file in CLF format: 150ms -> 137ms.

What the PR does is:

• Add locale independent IsSpace(char). Somewhat similar to 3aab90d, whitespace trimming perhaps should not be locale dependent.
• Add IsEmptyOrWhiteSpace() and use that inside ParseUtils::nextline, instead of doing Trim(line).empty().
• Add StringUtils::StartsWith(char) and use that in various parsers that were constructing whole std::string object just to check for a single character.
• When building for C++17 or later, NumberUtils can use standard <charconv> from_chars functions (except on Apple platforms, where those are not implemented for floating point types as of Xcode 15). This has advantage of not having to deal with errno or locales. Saves some thread local storage accesses and function calls (e.g. on Windows errno is actually a function call).
  • Turns out that NumberUtils::from_chars was only indirectly covered by tests, and as XML parser utils tests point out,
    it should be able to handle hex floats and so on. So all that is implemented there, and explicitly covered by
    tests/utils/NumberUtils_tests.cpp.
  • There's a CMake setup change that adds /Zc:__cplusplus flag for MSVC; for backwards compat reasons it does not report proper C++ version detection defines otherwise.

[remia]

Apologies for the delay in CI @aras-p, we have to manually approve the workflows due to our current GitHub settings. Trying to see if we can update that or merge your other PR which should also work.

[aras-p]

@remia thanks! I admit I did not expect that this PR would need so many failed iterations. <charconv> is a tough beast, it seems :)

[remia]

Doing some test on an Intel MBP, Xcode 16, it seems to still not support from_chars(). I did some quick benchmark and found nice speedups to load the same pbrNeutral.cube (from 140ms to 85ms on average to instanciate a Processor with the FileTransform pointing to the cube). Tested on a .spi3d file but this didn't seem to change the timings.

Looks good to me otherwise, thanks for the additional unit tests!

[cozdas]

Minor but to make sure:
Seems like __cpp_lib_to_chars "feature-test macros" are standardized in C++20, If I understand correctly -in theory- a C++17 compiler may not have this macro defined even if from_chars are implemented, thus we may have a false-negative here. Is that correct?

The worst case it'll fall back to slow path, so that's totally fine but I'm just curious.

[aras-p]

In theory, yes. In practice, this was the "least bad" way I found that would work on all of MSVC/clang/gcc, while also working on Apple Clang (in a sense that Apple Clang does not pass the test; from_chars on floats is still not there). In theory there could be some exotic compiler that might have from_chars for floats but not expose __cpp_lib_to_chars.

[aras-p]

Doing some test on an Intel MBP, Xcode 16, it seems to still not support from_chars()

Yeah, Apple's Clang/STL keeps on being "special". Some other software (e.g. Blender) works around this whole issue by embedding https://github.com/fastfloat/fast_float and using that instead of <charconv>

[cozdas]

Sorry for delayed response.
I wanted to double check that those changes won't break the other parts of the library where we need to deal with unicode strings but then pulled into different directions.

Are we sure that this "unsigned char" based IsSpace() function can operate reliably with UTF-8 encoded, potentially multi-byte characters? Especially the RightTrim() feels dangerous which is used in places like GetAbsoluteSearchPaths() etc.

[cozdas]

Hmm with a closer look, that doesn't seem to be using this overload. So the current use-case wise we're safe I guess.

[aras-p]

Yes this would work correctly with UTF-8 too, as in it would detect ASCII spaces just fine. UTF-8 is a full superset of 7-bit ASCII; any "longer than one byte" character bytes in there all have the highest bit set.

[cozdas]

Yup, you are right. MSB can be 0 only for the first byte of the multi-byte character.
All clear!

[cozdas]

Looks good.

[aras-p]

Now that two reviews have been done, is there something expected from my side to move forward with this PR?

[doug-walker]

@aras-p , apologies for the delay in getting this merged. Our CI system is currently having some problems which is causing checks to fail, but I don't think we will need you to do anything more on this one.

It's great to have your participation on OCIO -- we'll try to get your next PR merged more quickly! ;)