TestBigEndian: Performance

Development
1

TestBigEndian has performance problems.

TestBigEndian re-does a lot of work for no good reason.

If you have multiple projects checking for Endianness this can add up and eat at the configuration time.

The main reason that time is taken up is because of how the macro is written:

macro(TEST_BIG_ENDIAN VARIABLE)
  if(NOT DEFINED HAVE_${VARIABLE})
    message(STATUS "Check if the system is big endian")
    message(STATUS "Searching 16 bit integer")

If I have 3 different targets and they all call this macro, then a bunch of work is redone because they are different variables.

Ideally the result could be stored in a global property. Calculate it once, then cache the result in a global property.

Also an include_guard wouldn’t hurt.

2

Why not use a single variable for each of the detections? If you need separate variables afterwards, set the wanted name based on the common detection name.

3

I would guess they are independent projects that are brought in via FetchContent or other means that cause upstream changes to be hard to manage.

4

Some top-level coordination to set the second and third based on the first would also be a solution in this case.

5

I wrote an implementation of TestBigEndian that doesn’t require any coordination between projects.
I accomplish this by caching the results of the first call, and then just re-using it.

My implementation only fixes the performance issue with calling TestBigEndian over and over again with different variable names. This helps with projects that can’t coordinate the variable name.

@ben.boeckel, @robert.maynard, @YMba9g8j9CJp0wLoQf5y please give me your thoughts on the implementation I wrote.

1 Like
6

This implementation also fixes the performance cost of re-configurations. IE when you already built the project.

7

I have found myself in the circumstance where top-level coordination isn’t possible.

8

I’ve made a pull request to address this issue:
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5453

9

I’ve opened https://gitlab.kitware.com/cmake/cmake/-/issues/21392 with another proposed solution.

1 Like
10

Very cool to see CMAKE_LANG_BYTE_ORDER coming out of this!

Thank you Brad King!

11

Very cool to see CMAKE_LANG_BYTE_ORDER coming out of this!

While I think that the general idea to check this once and cache it is the
right thing, I’m not convinced that CMAKE__something is the right place
for this to end. This clearly isn’t language specific, in the same way as
CMAKE_SIZEOF_VOID_P isn’t. So why stuff it the LANG namespace?

Eike

12

CMAKE_<LANG>_BYTE_ORDER is detected from <LANG>'s toolchain and is only available after <LANG> has been enabled. CMAKE_SIZEOF_VOID_P is actually just copied from CMAKE_<LANG>_SIZEOF_DATA_PTR by every language that detects the latter.

1 Like