wip groupmembers is 2-alloc away.

README.md

@@ -274,20 +274,25 @@ Similarly, when user's groups are resolved in (2), they are not always necessary
 (i.e. not part of `struct user*`), therefore the memberships themselves are
 stored out of bound.
 
-`groupmembers` and `additional_gids` store group and user memberships respectively.
-Membership IDs are packed — not necessitating random access, thus suitable for
-compression.
+`groupmembers` and `additional_gids` store group and user memberships
+respectively. Membership IDs are packed — not necessitating random access, thus
+suitable for compression.
 
-- `groupmembers` is a list of pointers (offsets) to User records, because
-  `getgr*_r` returns pointers to membernames, thus a name has to be immediately
-  resolvable.
-- `additional_gids` is a list of gids, because `initgroups_dyn` (and friends) returns
-  an array of gids.
+- `groupmembers` consists of a number X followed by a list of offsets to User
+  records, because `getgr*_r` returns pointers to membernames, thus a name has
+  to be immediately resolvable.
+- `additional_gids` is a list of gids, because `initgroups_dyn` (and friends)
+  returns an array of gids.
 
-Each entry of `groupmembers` and `additional_gids` starts with a varint N, which is
-the number of upcoming elements, followed by N delta-compressed varints. These
-N delta-compressed varints are sorted the same way entries in `users` (in
-`groupmembers`) and `groups`.
+Each entry of `groupmembers` and `additional_gids` starts with a varint N,
+which is the number of upcoming elements. Then depending on the type:
+
+- **additional_gids** stores N delta-compressed varints. These varints
+  correspond to a list of gids.
+- **groupmembers** stores a total length of the member names, followed by N,
+  followed by N offsets. These are byte-offsets to the User records in the
+  `users` section. Having the length of membernames saves some CPU cycles when
+  decompressing the members in the hot path.
 
 Indices
 -------