Důvodem je zmenšení velikosti programu. Představte si, že váš program v jazyce C běží na vestavěném systému, kde jsou kód a všechny konstanty uloženy ve skutečné paměti ROM (flash paměti). V takových systémech musí být před voláním main() provedeno počáteční "copy-down", aby se nastavily všechny objekty doby trvání statického úložiště. Obvykle to bude vypadat takto pseudo:
for(i=0; i<all_explicitly_initialized_objects; i++)
{
.data[i] = init_value[i];
}
memset(.bss,
0,
all_implicitly_initialized_objects);
Kde jsou .data a .bss uloženy v RAM, ale init_value je uložena v ROM. Pokud by to byl jeden segment, pak by ROM musela být zaplněna spoustou nul, čímž se velikost ROM výrazně zvětšila.
Spustitelné soubory založené na RAM fungují podobně, i když samozřejmě nemají skutečnou ROM.
Memset je také pravděpodobně velmi účinný inline assembler, což znamená, že spouštěcí kopírování může být provedeno rychleji.
.bss segment je optimalizace. Celý .bss segment je popsán jedním číslem, pravděpodobně 4 bajty nebo 8 bajty, které udává jeho velikost v běžícím procesu, zatímco .data sekce je stejně velká jako součet velikostí inicializovaných proměnných. Tedy .bss umožňuje menší a rychlejší načítání spustitelných souborů. Jinak by proměnné mohly být v .data segment s explicitní inicializací na nuly; program by jen těžko poznal rozdíl. (Podrobně adresy objektů v .bss by se pravděpodobně lišila od adresy, pokud by byla v .data segmentu.)
V prvním programu a by bylo v .data segment a b by bylo v .bss segmentu spustitelného souboru. Jakmile je program načten, rozdíl se stane nepodstatným. Za běhu b zabírá 20 * sizeof(int) bajtů.
Ve druhém programu var je přidělen prostor a přiřazení v main() upravuje ten prostor. Stane se, že mezera pro var byl popsán v .bss segment spíše než .data segment, ale to neovlivňuje způsob, jakým se program chová při spuštění.