It's impressive how close to optimal this is.
You can beat the efficiency of 5 trits in 8 bits (1.6) with as few as 17 trits in 27 bits (~1.588), but once you account for rounding up to a whole number of bytes for practical reasons, then beating the efficiency requires going to at least 111 trits in 176 bits (~1.586), or perhaps more practically for fast unpacking, 161 trits in 256 bits (~1.59).
At that level, even if you have, say, 27B trits, the more efficient encodings would save something like 38-45MB (theoretical limit ~48MB), likely at the cost of some slowdown.
> You can beat the efficiency of 5 trits in 8 bits
The single trit packing is a commonly optimized DBNULL structure for booleans.
Bits/trit approaches the 1.5 asymptote, because that is the fundamental packing limit.
The trick is to use it when you have a trit to start with, like when you have a set which is a tiny bit over a power of two.
There are places where you end up with odd numbers in set sizes, for example when storing a poker hand.
Read Cactus Kev's trick[1] which I think needs a 27 bit section & optimizing it was where I first ran into trit packing.
[1] - http://suffe.cool/poker/evaluator.html