Przegląd Literatury

Wybór środowiska uruchomieniowego JavaScript stanowi decyzję architektoniczną o rosnącym znaczeniu w kontekście architektur bezserwerowych (serverless computing) i przetwarzania na urządzeniach brzegowych (edge computing). Ekosystem serwerowego JavaScript przeszedł w ostatnich latach istotną transformację: obok dominującego Node.js pojawiły się środowiska Deno~2 oraz Bun, oferując odmienne silniki wykonania kodu (V8 oraz JavaScriptCore), różne modele asynchroniczności i charakterystyki inicjalizacji. Podczas gdy dotychczasowe badania koncentrowały się na wymiarze wydajnościowym i latencji, aspekt energetyczny tego wyboru pozostaje obszarem praktycznie niezbadanym. Niniejszy przegląd systematyzuje stan wiedzy w czterech wzajemnie powiązanych obszarach: efektywności energetycznej języków i środowisk uruchomieniowych, narzędzi i metodologii pomiaru energii oprogramowania, architektury i wydajności platform bezserwerowych oraz zrównoważonego i świadomego węglowo przetwarzania w chmurze.

Efektywność Energetyczna Języków Programowania

Fundamenty empirycznego badania efektywności energetycznej oprogramowania zostały ustanowione przez Pereirę i współpracowników w serii wpływowych prac ¹². W pierwszym badaniu autorzy przeprowadzili systematyczną analizę 27 języków programowania z wykorzystaniem wskaźników Intel RAPL (\textit{Running Average Power Limit}) oraz zadań z Computer Language Benchmarks Game (CLBG), wykazując, że języki interpretowane zużywają wielokrotnie więcej energii niż skompilowane~¹. JavaScript w implementacji Node.js osiągnął wynik 4{,}45-krotnie gorszy od referencyjnego językaC, lokując się w środkowej części rankingu energetycznego. Co istotne, autorzy udokumentowali słabą korelację między czasem wykonania a zużyciem energii— wyniki, które będą miały kluczowe znaczenie dla interpretacji późniejszych benchmarków wydajnościowych Node.js/Bun/Deno.

Kontynuacja tych badań ² poszerzyła bazę eksperymentalną o zadania z repozytorium Rosetta Code oraz zastosowała wielokryterialną metodę TOPSIS do syntezy wyników w wymiarach energii, czasu i pamięci. JavaScript uplasował się na 15.miejscu spośród27~języków. Prace Pereiry et al. ustanowiły RAPL jako de facto standard narzędziowy w badaniach energetycznych oprogramowania i wypracowały wzorzec eksperymentalny (kontrolowane środowisko bare-metal, wielokrotne powtórzenia, testy statystyczne), który jest bezpośrednio adaptowany w niniejszym projekcie.

Uzupełnieniem tej linii badań jest praca Cunhy i współpracowników ³, w której zaproponowano ograniczanie mocy (power capping) przez mechanizm RAPL PKGP jako narzędzie świadomego zarządzania energią w programach wielojęzykowych. Autorzy zidentyfikowali zakres 70–80% limitu mocy jako optymalny dla języków skryptowych ~— obserwacja o potencjalnym znaczeniu przy projektowaniu protokołu pomiarowego dla środowisk uruchomieniowych JavaScript.

Bezpośrednim rozwinięciem powyższych badań w kierunku JavaScript jest praca De Macedo et al. ⁴, stanowiąca pierwsze systematyczne porównanie energetyczne JavaScript i WebAssembly. Autorzy wykazali, że moduły Wasm uruchamiane w Node.js (silnik V8) zużywają o20–30% mniej energii niż odpowiedniki napisane wJavaScript w zadaniach CPU-bound, pozostając przy tym wolniejszymi niż implementacje natywne. Ograniczeniem tej pracy jest jednak ekskluzywne skupienie na platformie Node.js z silnikiem V8~— wnioski nie uwzględniają środowisk opartych na JavaScriptCore (Bun) ani na Rust/Tokio (Deno), co stanowi bezpośrednią lukę wypełnianą przez proponowane badania.

Środowiska Uruchomieniowe JavaScript: Stan Wiedzy i Luki

Wydajność serwerowych środowisk uruchomieniowych JavaScript była przedmiotem kilku prac empirycznych, jednak żadna z nich nie uwzględniła wymiaru energetycznego. Smirnov i współpracownicy ⁵ przeprowadzili porównanie Node.js, Deno i Bun w warunkach laboratoryjnych, mierząc czas wykonania testów z Computer Language Benchmarks Game. Praca ta~— jedyne dostępne recenzowane zestawienie wszystkich trzech środowisk~— wykazała istotne różnice wydajnościowe, jednakże brak pomiaru energii jest wprost przyznany przez autorów jako ograniczenie metodologiczne.

Uzupełniające dane dostarcza praca Laakso ⁶, zawierająca benchmarki HTTP throughput, operacji pliku, parsowania JSON i obliczeń CPU-bound na platformie Apple Silicon (M2). Wyniki wskazują, że Bun (JavaScriptCore + Zig) osiąga przepustowość o42% wyższą niż Node.js w workloadach HTTP i o34% szybszy czas wykonania w zadaniach CPU-bound. Deno z natywnym API (Deno.serve) osiąga wyniki zbliżone do Node.js, natomiast przy użyciu warstwy kompatybilności z Node.js wykazuje spadek przepustowości o16%. Sondaż State of JavaScript 2024 (11,576 respondentów) dokumentuje rozkład adopcji: Node.js 90{,}8%, Bun 16{,}4%, Deno 11{,}8%, potwierdzając rosnące znaczenie alternatywnych środowisk⁶.

Kluczowa obserwacja wynikająca z porównania tych prac brzmi następująco: Node.js i Deno używają tego samego silnika V8 (Google Chrome), podczas gdy Bun opiera się na JavaScriptCore (Apple Safari) skompilowanym przez Zig. Odmienność silników implikuje różne charakterystyki kompilacji JIT, odśmiecania pamięci~(garbage collection) oraz startu zimnego (cold start)~— czynniki bezpośrednio determinujące zużycie energii. Dane o samej wydajności czasowej nie pozwalają przewidzieć tych różnic energetycznych, co stanowi centralną lukę badawczą adresowaną przez niniejszy projekt.

Narzędzia i Metodologia Pomiaru Energii Oprogramowania

Kluczowym narzędziem umożliwiającym pomiar energii na poziomie procesu jest PowerJoular, opisany przez Noureddine’a ⁷. Narzędzie to, napisane w języku Ada (jednym z najbardziej energooszczędnych języków programowania ²), monitoruje zużycie energii dowolnego procesu systemu operacyjnego poprzez identyfikację PID, wykorzystując interfejs Linux Power Capping Framework odczytujący rejestry Intel RAPL. Atrybucja energii do procesu realizowana jest proporcjonalnie do czasu CPU: $E_{p}roc=\frac{t_{C}PU,proc}{t_{C}PU,total}\cdot E_{p}kg$. Na platformach ARM (Raspberry Pi) PowerJoular stosuje modele regresji wielomianowej odwzorowujące CPU utilization na pobór mocy, z błędem 0{,}3–3{,}83%. Narzędzie jest bezpośrednio kompatybilne z Node.js, Deno i Bun bez modyfikacji kodu źródłowego tych środowisk~⁷. Należy odnotować ograniczenie wynikające z podatności PLATYPUS (Lipp et al., 2021): odczyt RAPL dla nieuprzywilejowanych procesów jest ograniczony przez jądro Linuksa, co w praktyce wymaga uruchomienia PowerJoular jako usługi systemd z uprawnieniami administratora.

Złożoność wielowarstwowego środowiska Kubernetes wymagała rozwinięcia bardziej zaawansowanych ram eksperymentalnych. Werner i współpracownicy ⁸ przedstawili CLUE (Cloud-native Sustainability Evaluator)~— zautomatyzowany framework do benchmarkowania efektywności energetycznej aplikacji cloud-native na Kubernetes. CLUE integruje trzy niezależne narzędzia pomiarowe (Kepler, Scaphandre, mierniki inteligentne Tapo P115) i mierzy energię równocześnie na wszystkich warstwach stosu: aplikacji, serwisów, platformy, izolacji i sprzętu. Eksperyment porównujący pięć wariantów architektonicznych referencyjnej aplikacji mikrousługowej ujawnił kontr-intuicyjny wynik: wariant serverless (KNative) charakteryzował się wyższym zużyciem energii niż bazowe mikrousługi, co autorzy przypisują kosztom infrastruktury KNative i efektom zimnych startów ⁸. Obserwacja ta podkreśla, że sama architektura bezserwerowa nie gwarantuje oszczędności energii— kluczowe jest to, jakiego środowiska uruchomieniowego używamy wewnątrz funkcji.

Wzorzec metodologiczny dla wieloczynnikowych eksperymentów energetycznych dostarcza praca Albonico et al. ⁹, porównująca zużycie energii komunikacji w ROS2 dla języków C++ i Python w funkcji częstotliwości komunikatów i liczby klientów. Autorzy stosują schemat eksperymentalny: język × częstotliwość × liczba uczestników, z medianami i zakresami międzykwartylowymi jako miarami głównymi, oraz test Manna-Whitneya U jako testem statystycznym. Podejście to stanowi bezpośredni wzorzec dla eksperymentu JE-EXP-1, w którym czynnikiem zastępującym języki są środowiska uruchomieniowe JavaScript, a czynnikami krzyżowymi— kategorie workloadów i tryby wykonania.

W kontekście środowisk bezserwerowych istotną metodologię atrybucji energii zaproponowali Rehman i współpracownicy w systemie FaasMeter ¹⁰. System ten disagreguje sumaryczny pobór mocy węzła na poszczególne funkcje FaaS za pomocą filtru Kalmana i wartości Shapleya, dostarczając per-funkcyjnych charakterystyk energetycznych bez konieczności izolacji sprzętowej. Kluczowe założenie FaasMeter~— że funkcje o podobnym CPU utilization mają zbliżony profil energetyczny~— będzie zweryfikowane w niniejszym projekcie: hipoteza JE-10 zakłada, że środowiska uruchomieniowe JavaScript falsyfikują to założenie poprzez odmienne charakterystyki silników JIT.

WebAssembly jako Alternatywne Środowisko Uruchomieniowe

WebAssembly (Wasm) stanowi alternatywny paradygmat wykonania kodu w środowiskach bezserwerowych i brzegowych, oferując potencjalnie krótsze zimne starty i mniejsze rozmiary artefaktów deploymentu kosztem ograniczonego dostępu do systemu operacyjnego przez interfejs WASI. Systematyczną analizę porównawczą środowisk Wasm i kontenerów na kontinuum krawędź–chmura przeprowadzili Marcelino et al. w frameworku Lumos ¹¹. Autorzy wykazali, że obrazy Wasm kompilowane ahead-of-time (AoT) są do 30-krotnie mniejsze niż odpowiadające obrazy kontenerowe i redukują opóźnienie zimnego startu o do 16%. Natomiast Wasm interpretowany~— wolniejszy o 30–55-krotnie w workloadach warm~— jest nieefektywny w warunkach produkcyjnych. Kluczowym wąskim gardłem zidentyfikowanym przez Lumos jest serializacja danych WASI, która dla intensywnych I/O workloadów może zwiększać czas wykonania nawet o95%¹¹.

Warto odnotować, że już Jangda et al.¹² wykazali, iż wydajność Wasm w praktyce ustępuje kodowi natywnemu o10–150%, głównie zpowodu narzutów niezwiązanych zsamym kodem (pośrednie wywołania, brakujące optymalizacje kompilatora) — co ogranicza oczekiwaną korzyść AoT nad JIT wrzeczywistych workloadach. Komplementarne wyniki dostarcza badanie Besozziego i współpracowników ¹³, porównujące Wasmtime i MicroVMs Firecracker ¹⁴ jako środowiska izolacji dla przetwarzania brzegowego. Mediana opóźnienia zimnego startu dla Wasm wynosi 5{,}6ms, wobec 93{,}5ms dla Firecracker i 29{,}4ms dla Firecracker z wstępnym ogrzewaniem (pre-warming)~¹³. Wasm oferuje zatem przewagę w scenariuszach o wysokiej częstości zimnych startów, lecz Firecracker zachowuje wyższą wydajność dla złożonych workloadów I/O-bound.

Colosi i współpracownicy ¹⁵ jako pierwsi wykonali te same artefakty Wasm na trzech środowiskach (przeglądarka, edge, chmura), dokumentując zróżnicowane profile latencji i zużycia pamięci. Przeglądarka osiąga konkurencyjne wyniki dla małych ładunków danych (16KiB) dzięki wykonaniu in-memory bez kosztów IPC, natomiast edge AOT dominuje przy dużych ładunkach (1MiB, 4MiB)¹⁵. Praca CWASI ¹⁶ uzupełnia ten obraz, proponując warstwę pośredniczącą dla komunikacji między funkcjami Wasm w trybie co-location, redukującą latencję IPC o~95% w stosunku do standardowego WasmEdge.

Wspólnym mianownikiem tych prac jest brak analizy zużycia energii~— zarówno w warunkach zimnego startu, jak i przy ustabilizowanym wykonaniu. Porównanie energetyczne Wasm AoT z JavaScriptCore (Bun) pozostaje otwartym pytaniem badawczym, szczególnie w kontekście urządzeń brzegowych opartych na architekturze ARM, gdzie oba środowiska mogą potencjalnie osiągać zbliżoną efektywność energetyczną.

Cold Start i Wydajność Platform Bezserwerowych

Zimny start jest uznawany za jedno z fundamentalnych wyzwań architektur bezserwerowych. Kompleksowa taksonomia tego problemu i jego rozwiązań jest zawarta w przeglądzie systematycznym Golec i współpracowników ¹⁷, obejmującym 32 prace z lat 2017–2023. Praca wyróżnia osiem kategorii rozwiązań (m.in. cache-based, design-based, snapshot-based) i dokumentuje zależność czasu zimnego startu od języka programowania: środowiska interpretowane, w tym JavaScript i Python, charakteryzują się krótszym zimnym startem niż środowiska JVM (.NET, Java), co autorzy tłumaczą mniejszym narzutem inicjalizacji maszyny wirtualnej~¹⁷. Kluczową luką zidentyfikowaną przez przegląd jest brak miar energetycznych~— autorzy wskazują wprost na potrzebę modeli uwzględniających energię przy autoskalowaniu i symulatorów środowisk brzegowych wrażliwych na zużycie energii.

Kontekst platform bezserwerowych jest dostarczany przez Li i współpracowników ¹⁸, którzy porównali cztery otwarte platformy (Knative, Kubeless, Nuclio, OpenFaaS) pod kątem przepustowości i latencji. Różnice w przepustowości sięgają rzędu wielkości w zależności od konfiguracji platformy i charakteru workloadu~¹⁸~— obserwacja podkreślająca, że wybór platformy jest zmienną konfudującą przy porównaniach energetycznych środowisk uruchomieniowych, którą należy kontrolować w protokole eksperymentalnym.

Kiener i współpracownicy ¹⁹ badali wewnętrzną równoległość funkcji bezserwerowych (intra-function parallelism), dokumentując fakt, że przydzielony vCPU nie odpowiada jednoznacznie fizycznemu rdzeniowi procesora na platformach chmurowych. Eksperymenty wykazały potencjalne oszczędności kosztowe rzędu 81% przy odpowiednim zrównolegleniu za pomocą worker_threads w Node.js~¹⁹. Wyniki te wskazują, że pomiary energii przeprowadzane bez kontroli nad mapowaniem vCPU/rdzeń mogą być mylące~— obserwacja istotna dla protokołu eksperymentalnego projektowanego w ramach badania JE-EXP-1.

Carl i współpracownicy ²⁰ rozszerzają analizę o wzorce przetwarzania strumieniowego (streaming workloads), dokumentując właściwości i ograniczenia środowisk bezserwerowych dla zadań krótko- i długotrwałych. Prezentowane wzorce architektoniczne mają bezpośrednie przełożenie na kategorię workloadów strumieniowych w eksperymencie JE-EXP-1.

Zrównoważone i Świadome Węglowo Przetwarzanie Bezserwerowe

Troska o ślad węglowy infrastruktury informatycznej stała się w ostatnich latach samodzielnym kierunkiem badań nad przetwarzaniem bezserwerowym. GreenCourier, zaproponowany przez Chadhę i współpracowników ²¹, stanowi pierwszą implementację harmonogramowania bezserwerowego świadomego intensywności węglowej sieci energetycznej. Wykorzystując dane WattTime o marginalnej emisji (MOER) i wieloklastrową federację Kubernetes przez Liqo, system dynamicznie kieruje wywołania funkcji do regionów o najniższym śladzie węglowym. Eksperymenty na infrastrukturze Google Kubernetes Engine potwierdziły redukcję emisji CO${}_2$ o 13{,}25% przy zaniedbywalnym narzucie harmonogramowania ²¹. Praca identyfikuje jednak fundamentalne ograniczenie: model przyjmuje stały ślad węglowy per wywołanie funkcji~— nie uwzględnia, że zmiana środowiska uruchomieniowego JavaScript może zmodyfikować energię per żądanie, a tym samym emisję CO${}_2$.

Serenari i współpracownicy rozwinęli analogiczne podejście w systemie GreenWhisk ²², implementując równoważenie obciążenia świadome emisji na platformie Apache OpenWhisk z wykorzystaniem API TryCarbonara jako źródła rzeczywistej intensywności węglowej sieci. Uzupełnieniem jest framework CASA ²³, realizujący dwucelową optymalizację (naruszenia SLO + emisja węglowa) za pomocą algorytmu heurystycznego z przełączaniem pomiędzy komponentem zachłannym i symulowanym wyżarzaniem. Eksperymenty na 50-węzłowym klastrze z obciążeniem Azure Function Trace2020 wykazały, że CASA redukuje zarówno emisje CO${}_2$, jak i liczbę naruszeń SLO w porównaniu z referencyjnymi schedulerami Kubernetes²³.

Najnowsze prace rozszerzają zakres optymalizacji poza samą emisję węglową. Sun i współpracownicy zaproponowali system LACE-RL ²⁴, w którym agent uczenia przez wzmocnienie (Deep Q-Network) dynamicznie dostosowuje czas utrzymania kontenerów przy życiu (keep-alive timeout) w środowisku bezserwerowym. Model energetyczny LACE-RL parametryzuje każdą funkcję przez energię zimnego startu $E_{c}old$ oraz współczynnik mocy spoczynkowej ${\lambda }_{i}dle=P_{i}dle/P_{a}ctive$. Eksperymenty na śladzie Huawei Public Cloud (31 dni, ponad 300 milionów wywołań) wykazały redukcję liczby zimnych startów o 51{,}69% i emisji węglowej spoczynku o 77{,}08% w porównaniu z polityką statyczną stosowaną w produkcji ²⁴. Wartości ${\lambda }_{i}dle$ zmierzone dla workloadów FunctionBench wahały się w zakresie 0{,}21–0{,}83~— świadcząc o silnym zróżnicowaniu charakterystyk energetycznych między typami funkcji.

Równolegle Tsenos i współpracownicy przedstawili system EES (Energy Efficient Scheduler) ²⁵, który za pomocą dynamicznego skalowania napięcia i częstotliwości (DVFS) i modelu kolejkowego M/M/c dobiera optymalną parę {częstotliwość CPU, liczba replik} dla każdej funkcji FaaS. Kluczowy wynik eksperymentalny: obniżenie częstotliwości z 4{,}0GHz do 3{,}6GHz powoduje spowolnienie wykonania o zaledwie 10%, ale redukuje zużycie energii o 22{,}5%²⁵. EES osiąga łączne oszczędności energii rzędu 14–28% w porównaniu z bazowym harmonogramowaniem Linux. Krytycznym założeniem systemu— bezpośrednio istotnym dla niniejszego projektu~— jest teza, że funkcje o zbliżonym CPU utilization mają zbliżone profile energetyczne. Środowiska uruchomieniowe JavaScript (V8 w Node.js i Deno kontra JavaScriptCore w Bun) mogą falsyfikować to założenie przez odmienne charakterystyki JIT i GC.

Najbardziej kompleksowe ujęcie problemu zrównoważoności w kontekście FaaS prezentuje framework SFCM ²⁶— pierwsza praca jednocześnie optymalizująca trzy cele środowiskowe: naruszenia SLO, emisje CO${}_2$ oraz zużycie wody chłodzącej (wastewater). Hybrydowy algorytm łączy przeszukiwanie lokalne, algorytm ewolucyjny i historię przeszukiwań, zwracając front Pareto możliwych konfiguracji. Wariant SFCM-Balance redukcuje naruszenia SLO o45%, emisje o25% i zużycie wody o26% w porównaniu z metodą referencyjną~²⁶. Wyniki te ilustrują, że optymalizacja przez wybór środowiska uruchomieniowego JavaScript~— redukująca energię per żądanie~— wpływałaby na wszystkie trzy wymiary środowiskowe jednocześnie.

Luki w Literaturze i Uzasadnienie Badania

Analiza przedstawionej literatury ujawnia spójny wzorzec niedoboru wiedzy, który niniejsze badanie bezpośrednio adresuje.

Brak energetycznego wymiaru porównania środowisk JS. Istniejące prace empiryczne porównujące Node.js, Deno i Bun~⁵⁶ ograniczają się wyłącznie do wymiaru wydajnościowego. Badania energetyczne języków programowania ¹² traktują JavaScript monolitycznie jako jeden runtime (Node.js), ignorując fundamentalne różnice między silnikami V8 (Node.js, Deno) a JavaScriptCore (Bun). Pierwsza rygorystyczna analiza energetyczna Node.js, Deno i Bun w~środowiskach bezserwerowych stanowi tym samym oryginalny wkład badawczy niemający precedensu w literaturze.

Brak standaryzowanego protokołu pomiarowego dla JS runtimes. Środowiska uruchomieniowe JavaScript wykazują specyficzne właściwości kompilacji JIT i odśmiecania pamięci, które powodują, że energie kolejnych wywołań tworzą niestacjonarny szereg czasowy~⁷. Żadna z analizowanych prac nie opracowała protokołu uwzględniającego efekt rozgrzewania JIT i spike’ów GC w kontekście pomiaru energii JavaScript. Systematyczna metodologia tego rodzaju, obejmująca testy stacjonarności Ljunga-Boxa i filtrowanie spike’ów, jest potrzebna dla rzetelnych porównań energetycznych.

Ignorowanie środowisk uruchomieniowych w modelach energetycznych FaaS. Modele optymalizacyjne LACE-RL ²⁴ i EES ²⁵ parametryzują zużycie energii wyłącznie przez CPU utilization i czas wykonania, przyjmując implicite stały profil energetyczny niezależny od środowiska uruchomieniowego. Analogicznie systemy carbon-aware scheduling (GreenCourier ²¹, GreenWhisk ²², CASA ²³) traktują emisję węglową per wywołanie jako stałą dla danej funkcji, nie uwzględniając, że substytucja Node.js przez Bun może ją systematycznie obniżyć. Parametry $E_{c}old$ i ${\lambda }_{i}dle$ modelu LACE-RL nigdy nie zostały zmierzone empirycznie w przekroju środowisk uruchomieniowych JavaScript, co stanowi otwarte pytanie badawcze z bezpośrednimi implikacjami dla efektywności systemów zarządzania keep-alive.

DVFS i heterogeniczność krzywych energii. Tsenos et al. ²⁵ wykazali, że krzywa zależności energii od częstotliwości CPU jest istotna dla efektywności harmonogramowania DVFS. Jednakże kształt tej krzywej dla środowisk uruchomieniowych JavaScript nie był dotychczas badany. V8 intensywnie korzysta z kompilacji JIT, przez co wyższe częstotliwości CPU mogą być proporcjonalnie bardziej opłacalne niż dla Bun (JavaScriptCore z kompilacją bardziej zbliżoną do AOT). Weryfikacja tej hipotezy otworzy nowy wymiar optymalizacji w schedulerach energooszczędnych.

Zrównoważoność poza emisją węglową. SFCM ²⁶ jako pierwszy framework jednoczesnej optymalizacji SLO, emisji i zużycia wody nie uwzględnia wymiaru środowiska uruchomieniowego. Bardziej efektywne energetycznie środowisko (Bun zamiast Node.js) redukuje bezpośrednio energie per żądanie, a przez nią emisje CO${}_2$ i ilość wody zużytej do chłodzenia~— tworząc potencjał dla runtime-aware wariantu SFCM.

Zestawiając powyższe luki, projekt \emph{Energetyczna Efektywność Środowisk Uruchomieniowych JavaScript} adresuje tę problematykę przez: (1)~pierwsze pomiary porównawcze energii dla Node.js, Deno i Bun w kontrolowanych warunkach eksperymentalnych; (2)~opracowanie standaryzowanego protokołu uwzględniającego specyfikę JIT i GC; (3)~empiryczne wyznaczenie parametrów $E_{c}old$ i ${\lambda }_{i}dle$ dla każdego środowiska; (4)~analizę krzywych energii × częstotliwość CPU w kontekście DVFS; (5)~model wielokryterialny integrujący wymiar energetyczny wyboru środowiska uruchomieniowego z istniejącymi ramami zrównoważonego przetwarzania bezserwerowego.

---

Bibliografia

Footnotes

1. Pereira et al. (2017). Energy Efficiency Across Programming Languages: How Do Energy, Time, and Memory Relate?. Proceedings of the 10th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2017). ↩ ↩² ↩³

2. Pereira et al. (2021). Ranking Programming Languages by Energy Efficiency. Science of Computer Programming, vol. 205, pp. 102609. ↩ ↩² ↩³ ↩⁴

3. Cunha et al. (2024). Trading Runtime for Energy Efficiency: Leveraging Power Caps to Save Energy across Programming Languages. Proceedings of the 17th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2024). ↩

4. De Macedo et al. (2022). WebAssembly versus JavaScript: Energy and Runtime Performance. Proceedings of the 2022 International Conference on ICT for Sustainability (ICT4S). ↩

5. Smirnov et al. (2024). A Comparative Analysis of the Performance of JavaScript Code Execution Environments: Node.js, Deno and Bun. Programming Systems and Computational Methods, pp. 109—123. ↩ ↩²

6. Laakso (2025). The Next Generation of Server-Side JavaScript Runtimes: Node.js, Deno and Bun. Turku University of Applied Sciences. ↩ ↩² ↩³

7. Noureddine (2022). PowerJoular and JoularJX: Multi-Platform Software Power Monitoring Tools. Proceedings of the 18th International Conference on Intelligent Environments (IE 2022). ↩ ↩² ↩³

8. Werner et al. (2025). A Comprehensive Experimentation Framework for Energy-Efficient Design of Cloud-Native Applications. arXiv:2503.08641 ↩ ↩²

9. Albonico, Cannizza, Wortmann (2025). Energy Efficiency in ROS Communication: A Comparison Across Programming Languages and Workloads. Frontiers in Robotics and AI, vol. 12. ↩

10. Rehman, Fuerst, Sharma (2024). FaasMeter: Energy-First Serverless Computing. arXiv:2408.06130 ↩

11. Marcelino et al. (2025). Lumos: Performance Characterization of WebAssembly as a Serverless Runtime in the Edge-Cloud Continuum. Proceedings of the 15th International Conference on the Internet of Things (IOT 2025). ↩ ↩²

12. Jangda et al. (2019). Not So Fast: Analyzing the Performance of WebAssembly vs.\ Native Code. Proceedings of the 2019 USENIX Annual Technical Conference (ATC 2019). ↩

13. Fiasco et al. (2025). WebAssembly and Unikernels: A Comparative Study for Serverless Computing at the Edge. arXiv:2509.09400 ↩ ↩²

14. Agache et al. (2020). Firecracker: Lightweight Virtualization for Serverless Applications. Proceedings of the 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI 2020). ↩

15. Colosi et al. (2025). Serverless Everywhere: A Comparative Analysis of WebAssembly Workflows Across Browser, Edge, and Cloud. arXiv:2512.04089 ↩ ↩²

16. Marcelino, Nastic (2023). CWASI: A WebAssembly Runtime Shim for Inter-function Communication in the Serverless Edge-Cloud Continuum. Proceedings of the ACM/IEEE Symposium on Edge Computing (SEC ‘23). ↩

17. Golec et al. (2024). Cold Start Latency in Serverless Computing: A Systematic Review, Taxonomy, and Future Directions. ACM Computing Surveys, vol. 37, pp. 111. ↩ ↩²

18. Li et al. (2019). Understanding Open Source Serverless Platforms: Design Considerations and Performance. Proceedings of the 5th International Workshop on Serverless Computing (WoSC ‘19). ↩ ↩²

19. Kiener, Chadha, Gerndt (2021). Towards Demystifying Intra-Function Parallelism in Serverless Computing. Proceedings of the 7th International Workshop on Serverless Computing (WoSC ‘21). ↩ ↩²

20. Carl et al. (2026). Serverless Abstractions for Short-Running, Lightweight Streams. ↩

21. Chadha, John, Gerndt (2023). GreenCourier: Carbon-Aware Scheduling for Serverless Functions. Proceedings of the 9th International Workshop on Serverless Computing (WoSC ‘23), co-located with ACM/IFIP Middleware 2023. ↩ ↩² ↩³

22. Serenari et al. (2024). GreenWhisk: Emission-Aware Computing for Serverless Platform. Proceedings of the 2024 IEEE International Conference on Cloud Engineering (IC2E 2024). ↩ ↩²

23. Qi et al. (2024). CASA: A Framework for SLO and Carbon-Aware Autoscaling and Scheduling in Serverless Cloud Computing. Proceedings of the 15th IEEE International Green and Sustainable Computing Conference (IGSC 2024). ↩ ↩² ↩³

24. Sun et al. (2026). Green or Fast? Learning to Balance Cold Starts and Idle Carbon in Serverless Computing. Proceedings of the 26th IEEE International Symposium on Cluster, Cloud, and Internet Computing (CCGrid 2026). ↩ ↩² ↩³

25. Tsenos, Peri, Kalogeraki (2024). Energy Efficient Scheduling for Serverless Systems. arXiv:2410.06695 ↩ ↩² ↩³ ↩⁴

26. Qi et al. (2024). A Framework for SLO, Carbon, and Wastewater-Aware Sustainable FaaS Cloud Platform Management. arXiv:2410.11875 ↩ ↩² ↩³