Draft: Refactor catom to reduce size of unobserved atoms

[frmdstryr]

@MatthieuDartiailh's discussion on "un-observable atoms" got me thinking.. Currently there is 4 bytes of wasted space in the CAtom struct due to padding (on 64bit systems) also even if atoms have no observers the ObserverPool* still takes 8 bytes of space.

This PR proposes a potential new structure that converts the ObserverPool* observers field into a uint32_t pool_index and collapses that into a packed struct with the bitfield. The new catom struct has no padding and is now 32 bytes (down from 40 bytes).

Since the ObserverPool* is gone it uses a new "ObserverPoolManager" and a new bitfield flag "has_observers" that manages the mapping of the pool_index to ObserverPool for each atom.

Since it reuses ObserverPools (instead of delete & new) it is quite a bit faster add adding/removing observers however the observer pool manager (currently) doesn't ever shrink in size.

So atoms with no observers save 8 bytes, but atoms with observers cost 4 more bytes if my math is right (since pointers are just moved to the ObserverPoolManager and the extra free slot takes 4 bytes per pool). A better pool manager could eliminate the free slots vector to make it 0 cost if there's any ideas?

Just throwing this out there for discussion, there's probably better ways to do it.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.67%. Comparing base (0750392) to head (b118b23).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #240   +/-   ##
=======================================
  Coverage   97.67%   97.67%           
=======================================
  Files          24       24           
  Lines        1074     1074           
  Branches      162      162           
=======================================
  Hits         1049     1049           
  Misses         12       12           
  Partials       13       13           

[frmdstryr]

Well idk why it says the sizeof(ObserverPool*) is 24 bytes, it's 8 on my computer...

[MatthieuDartiailh]

On an unrelated note, we will have to move away from global statics (subinterpreters and free threaded python).

[frmdstryr]

Interesting... will have to do some more reading. From a quick scan I can't see how subinterpreters improve anything (given their examples shows pickling objects between them).

[frmdstryr]

I realize this PR is likely not going anywhere but tried changing the ObserverPoolManager

std::vector<ObserverPool> m_pools;

Which should delete 8 bytes per observed atom... but doing so causes segfaults when running the example from #239 (comment) for reasons I can't explain. Yet it passes all atom tests and enaml tests...

Edit: Figured it out from the cpp docs... "When emplace_back causes the size to change all iterators become invalid..."

[frmdstryr]

This will just cause more issues going forward due to the upcoming changes mentioned by Matthieu.