# TestBigEndian: Performance
**URL:** https://discourse.cmake.org/t/testbigendian-performance/1248
**Category:** Development
**Created:** [May 21, 2020, 4:24am UTC](https://discourse.cmake.org/t/testbigendian-performance/1248 "2020-05-21T04:24:59Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@YMba9g8j9CJp0wLoQf5y](https://discourse.cmake.org/u/YMba9g8j9CJp0wLoQf5y)
#### Post date: [May 21, 2020, 4:24am UTC](https://discourse.cmake.org/t/testbigendian-performance/1248/1 "2020-05-21T04:24:59Z")
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:
```auto
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.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [May 21, 2020, 12:38pm UTC](https://discourse.cmake.org/t/testbigendian-performance/1248/2 "2020-05-21T12:38:47Z")
> [@YMba9g8j9CJp0wLoQf5y](#):
>
> then a bunch of work is redone because they are different variables.
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.
---
### Author:  [@robert.maynard](https://discourse.cmake.org/u/robert.maynard)
#### Post date: [May 21, 2020, 5:21pm UTC](https://discourse.cmake.org/t/testbigendian-performance/1248/3 "2020-05-21T17:21:08Z")
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.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [May 23, 2020, 12:06pm UTC](https://discourse.cmake.org/t/testbigendian-performance/1248/4 "2020-05-23T12:06:26Z")
Some top-level coordination to set the second and third based on the first would also be a solution in this case.
---
### Author:  [@anon45792294](https://discourse.cmake.org/u/anon45792294)
#### Post date: [October 26, 2020, 12:30pm UTC](https://discourse.cmake.org/t/testbigendian-performance/1248/5 "2020-10-26T12:30:59Z")
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.
> **[hdf89shfdfs/cmake\_test\_endian\_is\_slow](https://github.com/hdf89shfdfs/cmake_test_endian_is_slow)**
>
> Show how slow test endian is. Contribute to hdf89shfdfs/cmake\_test\_endian\_is\_slow development by creating an account on GitHub.
@ben.boeckel, @robert.maynard, @YMba9g8j9CJp0wLoQf5y please give me your thoughts on the implementation I wrote.
---
### Author:  [@anon45792294](https://discourse.cmake.org/u/anon45792294)
#### Post date: [October 26, 2020, 12:32pm UTC](https://discourse.cmake.org/t/testbigendian-performance/1248/6 "2020-10-26T12:32:00Z")
This implementation also fixes the performance cost of re-configurations. IE when you already built the project.
---
### Author:  [@anon45792294](https://discourse.cmake.org/u/anon45792294)
#### Post date: [October 26, 2020, 12:41pm UTC](https://discourse.cmake.org/t/testbigendian-performance/1248/7 "2020-10-26T12:41:23Z")
I have found myself in the circumstance where top-level coordination isn’t possible.
---
### Author:  [@anon45792294](https://discourse.cmake.org/u/anon45792294)
#### Post date: [October 31, 2020, 11:13pm UTC](https://discourse.cmake.org/t/testbigendian-performance/1248/8 "2020-10-31T23:13:01Z")
I’ve made a pull request to address this issue:
[https://gitlab.kitware.com/cmake/cmake/-/merge\_requests/5453](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5453)
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [November 3, 2020, 8:12pm UTC](https://discourse.cmake.org/t/testbigendian-performance/1248/9 "2020-11-03T20:12:04Z")
I’ve opened [https://gitlab.kitware.com/cmake/cmake/-/issues/21392](https://gitlab.kitware.com/cmake/cmake/-/issues/21392) with another proposed solution.
---
### Author:  [@anon45792294](https://discourse.cmake.org/u/anon45792294)
#### Post date: [November 7, 2020, 1:41am UTC](https://discourse.cmake.org/t/testbigendian-performance/1248/10 "2020-11-07T01:41:15Z")
Very cool to see `CMAKE_LANG_BYTE_ORDER` coming out of this!
Thank you Brad King!
---
### Author:  [@Dakon](https://discourse.cmake.org/u/Dakon)
#### Post date: [November 7, 2020, 1:34pm UTC](https://discourse.cmake.org/t/testbigendian-performance/1248/11 "2020-11-07T13:34:33Z")
> 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
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [November 9, 2020, 1:24pm UTC](https://discourse.cmake.org/t/testbigendian-performance/1248/12 "2020-11-09T13:24:49Z")
> [@Dakon](#):
>
> So why stuff it the LANG namespace?
`CMAKE__BYTE_ORDER` is detected from ``'s toolchain and is only available after `` has been enabled. `CMAKE_SIZEOF_VOID_P` is actually just copied from `CMAKE__SIZEOF_DATA_PTR` by every language that detects the latter.