Optymalizacja ułożenia (doboru ścieżek i wyboru bloków) instrukcji kompilowanego programu przerywających liniowość maszynowego przepływu wykonania w wątku procesora (skoków oraz procedur) nie jest optymalizacją projektowania oprogramowania, lecz jest optymalizacją wyrażenia programu tekstowego w formie maszynowej, podczas gdy implementacja projektowanego programu — dokonywana w zapisie jego instancji oraz z reguł języka programowania — nie jest w tym zdaniu określona. Optymalizacja taka jest dokonywana przez kompilator, ponieważ programista nie ma możliwości poznania działania programu przed jego wykonywaniem się w rzeczywistości, i jest związana z kosztami czasowymi realizacji określonego bloku programu. W systemie OUX, który jest ·systemem czasu rzeczywistego nie wymuszającym priorytetów· fragmentów programu (czyli procedur w sensie ideowym) dla fundamentalnej zasady nieniszczenia zadania użytkownika realizowanego przez system w całości — programista zakłada najdłuższy czas wykonywania się instrukcji języka implementacji, który jest językiem wysokiego poziomu zachowującym deterministyczny i nieproceduralny związek z językiem maszynowym na gruncie przepływu wykonania i przepływu danych (jak określone w koncepcji opRWTng i ostatecznie w OUX). Najdłuższy czas wykonania instrukcji jest gwarantowany przez deterministycznie określoną najdłuższą drogę przepływu wykonania w wymienionym na początku tego tekstu ułożeniu instrukcji maszyny, którego może dokonać kompilator automatycznie. Natomiast ten czas nigdy nie może być określany na podstawie błędnej koncepcji systemu rzeczywistego stosowanej w systemach operacyjnych z priorytetami procedur, ponieważ priorytety procedur (procesów zadań, wątków, przerwań, itp.) wyszczególniają anonimowe podsystemy, które mają być zintegrowane samodzielnie od systemu operacyjnego na wypadek awarii niedotrzymania terminu czasowego względem rzeczywistości w jakimś programie sterowania urządzeniem, a taka anonimowa integralność jest i podzielona podsystemami, i przypadkowa — nie jest jawna dla projektanta, więc program nie realizuje zadania w każdym przypadku znanym przez projektanta. Projektant‐programista musi zakładać zawsze ten najdłuższy czas wykonania instrukcji realizacji bloku pomiędzy dwoma kolejnymi ‹raportami›, nie pamiętając jego ścisłej wartości liczbowej, ale przyjmując dla grup instrukcji implementacji pewną wartość standaryzowaną, większą niż czas wykonania najdłuższego ułożenia maszynowego na konkretnej maszynie. Tylko tam gdzie musi być w projekcie oprogramowania synchronizowany ‹raport› z jego przyczyną rzeczywistą, a nie wystarczy integralność wewnętrzna programu w realizacji zadania użytkownika bez względu na zmiany zewnętrzne; to ostatnie jest podstawowym celem OUX, a to pierwsze jest koniecznością wykonawczą.
Dlatego dzięki językowi wysokiego poziomu (obecnie CouxOstatecznie C+.) opartemu na rzeczywistych determinizmach, nie będącego rozszerzeniem języka maszynowego, ale syntezą rzeczywistą — projektant‐programista systemu rzeczywistego (a nie wirtualnego) może utworzyć oprogramowanie, które będzie realizowało jego rzeczywiste zadanie w sposób oczekiwany, nie negując fałszywymi gwarancjami obecnie istniejących systemów czasu rzeczywistego, że program komputerowy jest narzędziem człowieka tylko wtedy, gdy jest cały czas ujednolicany do znanej przez człowieka rzeczywistości, a sama konserwacja oprogramowania tym nie jest.
Na przykład kompilator ‟gcc” realizuje funkcję profilowania statystycznego oprogramowania, które po zebraniu danych wykonywania programu jest stosowane w rekompilacji z opcją “-fbranch-probabilities”. Tę opcję należy rozumieć wyłącznie w ramach sensu podanego w pierwszym akapicie tego tekstu. Nie wolno jej stosować zgodnie z sugestią, że statystycznie wyszukuje ona ·najczęściej· wykonywaną ścieżkę wykonania dla statystycznie ·najczęstszych· przypadków, w szczególności po to, by zarządzać kosztami serwisowania oprogramowania! Ta opcja może służyć tylko do stosowania opisanej optymalizacji tylko w warunkach ściśle zdefiniowanego determinizmu zachowania kompilatora ‟gcc”, wymuszonego stosowaniem określonego ścisłego podstandardu języka programowania oraz zastosowaniem określonych opcji kompilatora (pośród których może być “-O3”) — na podstawie określenia sposobu budowy programu przez ‟gcc” we wszystkich stosowanych przez projektanta‐programistę w implementacji w języku programowania przypadkach. I tak ‟gcc”, który jest oprogramowaniem swobodnym, poza standardami języków oprogramowania mimo ich cząstkowych implementacji — może być zastosowany do kompilacji oprogramowania nieopartego na tych właśnie standardach (np. C i ‘unix’), ale opartego na standardzie własnym, który nie bazuje na opisanym złudnym podejściu do gwarancji zapewnianych przez procedury bez związku z maszyną.
Jest to notatka, która nie zawiera określenia związku implementacji wspólnej języków programowania w opisanych rzeczywistych zależnościach.