Page MenuHome

BLI: Use no_unique_address attribute.
ClosedPublic

Authored by Jacques Lucke (JacquesLucke) on May 20 2022, 11:45 AM.

Details

Summary

Even though the no_unique_address attribute has only been standardized in C++20, compilers seem to support it with C++17 already.
This attribute allows reducing the memory footprint of structs which have empty types as data members (usually that is an allocator or inline buffer in Blender).
Previously, one had to use the empty base optimization to achieve the same effect which requires a lot of boilerplate (https://en.cppreference.com/w/cpp/language/ebo).

More info about the attribute: https://en.cppreference.com/w/cpp/language/attributes/no_unique_address

The types that benefit from this attribute the most are Vector and Array:

Type             Old        New
-------------------------------
Array<int>        40         32
Array<int, 0>     24         16
Vector<int>       48         40
Vector<int, 0>    32         24

All types which use these core data structures get smaller as well of course.

Diff Detail

Repository
rB Blender
Branch
no-unique-address (branched from master)
Build Status
Buildable 22179
Build 22179: arc lint + arc unit

Event Timeline

Jacques Lucke (JacquesLucke) requested review of this revision.May 20 2022, 11:45 AM
Jacques Lucke (JacquesLucke) created this revision.
Hans Goudey (HooglyBoogly) added inline comments.
source/blender/blenlib/BLI_vector.hh
75

Hopefully this change from private to public isn't necessary?

source/blender/blenlib/BLI_memory_utils.hh
324

Shouldn't this comment be updated now?

Ray Molenkamp (LazyDodo) requested changes to this revision.May 20 2022, 3:19 PM

The msvc implementation is special, the attribute does nothing unless you use msvc::no_unique_address

https://godbolt.org/z/KxveeGq4x

This revision now requires changes to proceed.May 20 2022, 3:19 PM
  • more cases
  • use macro for msvc support

The windows implementation is ok, since our lower bar is 16.9 which this attribute got added in, so in the clear there, I'm unsure where exactly our gcc/clang bar sits ? should we guard this with some kind of test in cmake to see if the compiler supports it?

I'm not sure a guard is necessary.

All attributes unknown to an implementation are ignored without causing an error. (https://en.cppreference.com/w/cpp/language/attributes)

I'm not sure a guard is necessary.

All attributes unknown to an implementation are ignored without causing an error. (https://en.cppreference.com/w/cpp/language/attributes)

fair enough, just trying to keep the "my build broke!" support costs down :)

Ok, check other compilers we support. Found that clang 8 compiles, but generates warnings: https://godbolt.org/z/MGcd5eMMe
Since we still support clang 8 (https://wiki.blender.org/wiki/Building_Blender#Compiler_Versions), it would be good to check for that somehow. Not sure where the right place for that check would be. I couldn't find similar checks for clang right now.

  • Merge branch 'master' into no-unique-address
  • fix clang warning
This revision is now accepted and ready to land.May 25 2022, 4:21 PM
This revision was automatically updated to reflect the committed changes.