Zároveň vývojáři zjistili, že kompilátor C++, kterým je Chrome sestavován, ne vždy dobře optimalizuje rozložení polí v paměti. Když jsou například v paměti umístěny dvě proměnné typu boolean, měly by obsadit sousední bity v jednom slově nebo využít volné bity v už používané paměti.
To by mě zajímal zdroj, jestli je to překladem, nebo si to skutečně myslí vývojáři Chrome. Kompilátor by v žádném případě neměl přehazovat proměnné a už vůbec ne skládat dvě boolean proměnné do různých bitů. Jakou by měl takový boolean potom adresu (pointer) ? Pokud to postačuje, může se explicitině použít bit field. Racionální organizace struktury podle toho, aby dobře fungovala na 32-bit i 64-bit architektách (s 16-bytovým celkovým zarovnáním), by měla být už součástí návrhu.
Kompilátor se ale ne vždy chová správně, proto se vývojáři rozhodli tuto optimalizaci provádět sami.
Kompilátor se chová naprosto správně a hlavně konzistentně a stejně jako všechny jiné kompilátory na dané platformě s daným ABI. Pokud by se choval jinak, nebude kompatibilní se zbytkem systému, ani knihovnami, ani jádrem.
Odkaz na zdroj je na začátku článku. Ano, originál vyznívá jinak.
Another improvement results from better packing of fields in abstract syntax tree nodes generated by the parser. Previously we relied on the C++ compiler to pack fields together where possible. For example, two booleans just require two bits and should be located within one word or within the unused fraction of the previous word. The C++ compiler doesn’t not always find the most compressed packing, so we instead manually pack bits. This not only results in reduced peak memory usage, but also improved parser and compiler performance.