Dans la version de base, l'overhead est de 16 octets par bloc. Si l'on désactive la possibilité de travailler dans un espace global de plus de 2 Go, (et c'est le cas dans la version TI), il tombe à 8 octets. Je crois que ce sont des valeurs à peu près classiques.
En plus de ça, lorsqu'on active l'heuristique, il y a 512 octets pour la table d'exponentielles précalulées, ainsi que moins de 1 ko pour les files qui servent à réaliser les statistiques.

L'autre facteur de perte de place qu'il faut prendre en compte dans tout système d'allocation (dis moi si je me trompe), c'est l'alignement. Actuellement, mes blocs ont une taille réelle multiple de 64 octets sur un système 64 bits, et 32 octets sur un système 32 bits. Je suis en train de réduire ça, pour tomber à 24 octets sur un système 32 bits et 48 octets sur un système 64 bits.

Actuellement, la place perdue en moyenne par bloc est donc de 8+32/2 = 24 octets sur un système 32 bits, et 16+64/2 = 48 octets sur un système 64 bits où on a autorisé la gestion de plus de 2 Go. On passera à 20 - 40 avec la prochaine version.
Sur ton système, si j'ai bien compris, elle est de 1/8+32/2 = 16.125 octets par bloc.

Pour répondre à ta dernière question, on peut effectivement perdre des branches de l'arbre en cas d'overflows. Je suis tenté de te répondre de manière statistique. Prenons un système 64 bits. Il y aura en moyenne 24 octets inutiles par bloc à cause de l'alignement. La probabilité de péter l'allocateur par un dépassement de q octets serait donc de q/24. Par exemple, un dépassement de 4 octets aura une probabilité de faire planter le système de 1/6. Bon le calcul est très grossier, c'est plus compliqué que ça.