Z natury abstrakcja ogranicza komunikację informacji zarówno dla programisty, jak i niższych warstw systemu (kompilatora, bibliotek i systemu wykonawczego). Na korzyść abstrakcji, ogólnie pozwala to dolnym warstwom założyć, że programista nie jest zainteresowany żadnym nieokreślonym zachowaniem, zapewniając większą elastyczność w dostarczaniu określonego zachowania.
Przykładem potencjalnej korzyści z tego aspektu „nie przejmuj się” jest układ danych. W C (niski poziom abstrakcji) kompilator jest bardziej ograniczony w optymalizacji układu danych. Nawet jeśli kompilator może rozpoznać (np. Poprzez informacje profilowe), że optymalizacje unikania dzielenia się na gorąco lub na zimno lub unikania fałszywego współdzielenia byłyby korzystne, generalnie nie można tego zastosować. (Istnieje pewna swoboda w określaniu „tak jakby”, tj. Traktowaniu specyfikacji bardziej abstrakcyjnie, ale czerpanie wszystkich potencjalnych efektów ubocznych stanowi obciążenie dla kompilatora.)
Bardziej abstrakcyjna specyfikacja jest również bardziej odporna na zmiany kompromisów i zastosowań. Niższe warstwy są mniej ograniczone w ponownej optymalizacji programu pod kątem nowych właściwości systemu lub nowych zastosowań. Bardziej konkretna specyfikacja musi albo zostać przepisana przez programistę, albo dolne warstwy muszą podjąć dodatkowy wysiłek, aby zagwarantować zachowanie „jak gdyby”.
Aspektem utrudniającym wydajność w przypadku abstrakcji informacji jest „nie można wyrazić”, co niższe warstwy zwykle obsługują jako „nie wiem”. Oznacza to, że niższe warstwy muszą rozróżniać informacje przydatne do optymalizacji od innych środków, takich jak typowe ogólne zastosowanie, ukierunkowane użycie lub określone informacje o profilu.
Wpływ ukrywania informacji działa również w innym kierunku. Programista może być bardziej produktywny, nie biorąc pod uwagę i nie określając każdego szczegółu, ale może mieć mniej informacji na temat wpływu wyborów projektowych wyższego poziomu.
Z drugiej strony, gdy kod jest bardziej szczegółowy (mniej abstrakcyjny), niższe warstwy systemu mogą po prostu robić to, co im każą, tak jak im każą. Jeśli kod jest dobrze napisany pod kątem jego docelowego użycia, będzie dobrze pasował do jego docelowego użycia. Mniej abstrakcyjny język (lub paradygmat programowania) pozwala programiście zoptymalizować implementację poprzez szczegółowy projekt i wykorzystanie informacji, które nie są łatwo przekazywane w danym języku do niższych warstw.
Jak zauważono, mniej abstrakcyjne języki (lub techniki programowania) są atrakcyjne, gdy dodatkowe umiejętności i wysiłek programisty mogą przynieść wartościowe wyniki. Przy zastosowaniu większego wysiłku i umiejętności programisty wyniki zazwyczaj będą lepsze. Ponadto system językowy, który jest rzadziej wykorzystywany w aplikacjach krytycznych pod względem wydajności (zamiast kładzenia nacisku na wysiłek programistyczny lub niezawodność - kontrole granic i odśmiecanie nie dotyczą wyłącznie wydajności programisty, ale także poprawności, abstrakcja zmniejszająca obciążenie umysłowe programisty może poprawić niezawodność) będzie miał mniejszy nacisk na poprawę wydajności.
Swoistość działa również wbrew zasadzie „nie powtarzaj się”, ponieważ optymalizacja jest zazwyczaj możliwa poprzez dostosowanie kodu do określonego zastosowania. Ma to oczywiste konsekwencje dla niezawodności i wysiłku programistycznego.
Abstrakcje dostarczane przez język mogą również obejmować niepożądane lub niepotrzebne prace bez możliwości wyboru mniejszej wagi abstrakcji. Podczas gdy dolne warstwy mogą czasem wykryć i usunąć niepotrzebną pracę (np. Kontrole granic mogą być wydobyte z bryły pętli i całkowicie usunięte w niektórych przypadkach), ustalenie, że taka poprawność jest poprawna, wymaga więcej „umiejętności i wysiłku” przez kompilator.
Wiek języka i popularność są również ważnymi czynnikami, zarówno pod względem dostępności wykwalifikowanych programistów, jak i jakości niższych warstw systemu (w tym dojrzałych bibliotek i przykładów kodu).
Innym mylącym czynnikiem w takich porównaniach jest nieco ortogonalna różnica między kompilacją z wyprzedzeniem a kompilacją just-in-time. Podczas gdy kompilacja just-in-time może łatwiej wykorzystywać informacje o profilu (nie polegając na programiście w celu zapewnienia uruchamiania profilów) i optymalizację specyficzną dla systemu (kompilacja z wyprzedzeniem może być ukierunkowana na szerszą kompatybilność), narzut agresywnej optymalizacji jest rozliczany jako część wydajności środowiska wykonawczego. Wyniki JIT mogą być buforowane, co zmniejsza obciążenie powszechnie używanego kodu. (Alternatywa binarnej ponownej optymalizacji może zapewnić pewne zalety kompilacji JIT, ale tradycyjne binarne formaty dystrybucji upuszczają większość informacji o kodzie źródłowym, potencjalnie zmuszając system do próby rozróżnienia zamiarów konkretnej implementacji.)
(Niższe języki abstrakcji, ze względu na ich nacisk na sterowanie programistą, sprzyjają stosowaniu kompilacji z wyprzedzeniem. Kompilacja w czasie instalacji może być tolerowana, chociaż wybór implementacji w czasie łącza zapewni większą kontrolę programisty. Kompilacja JIT poświęca znaczącą kontrolę. )
Istnieje również kwestia metodologii analizy porównawczej. Taki sam wysiłek / umiejętności są praktycznie niemożliwe do ustalenia, ale nawet jeśli można je osiągnąć, cele językowe mogą wpłynąć na wyniki. Gdyby wymagany był niski maksymalny czas programowania, program dla mniej abstrakcyjnego języka może nawet nie zostać całkowicie napisany w porównaniu z prostym wyrażeniem idiomatycznym w bardziej abstrakcyjnym języku. Gdyby dozwolony był wysoki maksymalny czas / wysiłek programowania, języki o niższej abstrakcji miałyby przewagę. Testy porównawcze przedstawiające wyniki najlepszych starań byłyby oczywiście stronnicze na korzyść mniej abstrakcyjnych języków.
Czasami jest możliwe programowanie w mniej idiomatyczny sposób w języku, aby zyskać zalety innych paradygmatów programowania, ale nawet gdy dostępna jest moc ekspresji, kompromisy w tym zakresie mogą nie być korzystne.