Dyskusja

Przeprowadzone eksperymenty dostarczyły pierwszych rygorystycznych danych energetycznych dla trójki współczesnych środowisk uruchomieniowych JavaScript w kontekście serverless. Wyniki potwierdzają część postawionych hipotez, ale ujawniają też nieoczekiwane odwrócenia rankingów wspecyficznych kategoriach workloadów, sugerując, że mechanizmy silnika JS wchodzą w złożone interakcje zcharakterystyką obciążenia. Poniżej interpretujemy wyniki przez pryzmat znanych mechanizmów JIT iGC, porównujemy zliteraturą oraz wyciągamy implikacje dla inżynierów i badaczy.

Interpretacja Wyników

Dominacja Bun przy workloadach I/O-bound. Najsilniejszy zaobserwowany efekt — redukcja energii o~$74$ dla Bun względem Node.js przy workloadach I/O-bound — wymaga wyjaśnienia mechanistycznego, ponieważ nie wynika wprost z charakterystyki silnika JS. WBun operacje wejścia/wyjścia realizowane są przez natywne wywołania systemowe bez pośredniej warstwy libuv (stosowanej wNode.js), co eliminuje narzut pętli zdarzeń i synchronizacji wątku sieciowego. Deno pośredniczy: jego asynchroniczny runtime Tokio/Rust jest efektywniejszy niż libuv Node.js ($-19$), ale ustępuje natywnemu podejściu Bun. Wynik jest spójny zdanymi wydajnościowymi Laakso¹, który zmierzył przepustowość Bun na poziomie $103000$ req/s vs $73000$ req/s dla Node.js i Deno — jednak nasze wyniki pokazują, że przewaga energetyczna Bun jest proporcjonalnie większa niż przewaga czasowa (odpowiednio $74$ vs $41$), co potwierdza hipotezę H3: różnice energetyczne są większe niż różnice czasowe z~uwagi na narzut JIT profiling.

Node.js jako lider energetyczny przy SSR. Odkrycie, że Node.js jest energetycznie najlepszy przy renderowaniu po stronie serwera, stoi wpozornej sprzeczności zogólnym trendem. Workload SSR intensywnie korzysta zkonkatenacji ciągów znakowych ikonstruowania drzew DOM-like — operacji, dla których silnik V8 wNode.js dysponuje dedykowanymi optymalizacjami Turbofan wypracowywanymi przez ponad dekadę wdrożeń produkcyjnych (Next.js, Nuxt.js). JavaScriptCore (Bun) ma mniejsze doświadczenie produkcyjne w SSR, co przekłada się na mniej agresywne specjalizacje kodu JIT dla tych wzorców. De Macedo et al.² obserwowali podobną specjalizację Node.js/V8 dla workloadów stringowych wkontekście Wasm vs JavaScript. Wynik ma bezpośrednią implikację: migracja aplikacji Next.js zNode.js na Bun nie przyniesie oszczędności energetycznych w~tej warstwie bez uprzedniej analizy charakterystyki workloadu.

Przewaga Deno przy workloadach memory-bound. Deno osiągnął najniższe zużycie energii ($112$J) przy operacjach na dużych tablicach ($-17$ vs Node.js, $-16$ vs Bun). Możliwym wyjaśnieniem jest agresywniejsza kompilacja Maglev/Turbofan uruchamiana wcześniej przez Deno 2.x dla długożyjących procesów — aworkload memory operuje na stabilnych strukturach, co sprzyja głębszej specjalizacji. Warto odnotować, że Deno 2.x zmienił model zarządzania pamięcią względem wcześniejszych wersji, zbliżając się do Node.js w obsłudze Typed Arrays ³. Wynik ten wskazuje na niedostateczne pokrycie przez istniejące benchmarki wydajnościowe (Smirnov 2024, Laakso 2025), które skupiają się na HTTP throughput pomijając workloady pamięciocentryczne.

Amortyzacja JIT adecyzje o utrzymaniu ciepłej instancji. Eksperyment JE-EXP-4 wyznaczył próg amortyzacji JIT dla V8 na poziomie $N\approx 500$wywołań, poniżej którego energia per wywołanie jest wielokrotnie wyższa niż wstanie steady-state. Ma to bezpośrednie konsekwencje dla środowisk FaaS: funkcja obsługująca ruch rzędu kilkuset wywołań dziennie (typowy przypadek low-traffic serverless) może nigdy nie osiągnąć plateau efektywności V8. Bun, ze swoim wcześniejszym plateau ($N\approx 100$) ibrakiem wielopoziomowego JIT, oferuje bardziej przewidywalne zużycie energii niezależnie od częstotliwości wywołań — co czyni go szczególnie atrakcyjnym dla sporadycznie wywoływanych funkcji FaaS. Obserwacja ta uzupełnia model LACE-RL Sun et al. (2026), który zakłada stały parametr energetyczny per runtime — nasze dane pokazują, że parametr ten jest silnie zależny od liczby wywołań per instancja.

\paragraph{Jednorodność ${\lambda }_{idle}$ iwalidacja modelu LACE-RL.} Zaskakującym wynikiem eksperymentu JE-EXP-5 jest praktyczna identyczność ${\lambda }_{idle}\approx 0,20$ dla wszystkich trzech runtimeów. Wmodelu LACE-RL parametr ten decyduje ooptymalnym czasie utrzymania ciepłej instancji (TTL keep-alive) — jego jednorodność oznacza, że \emph{wybór środowiska uruchomieniowego nie powinien wpływać na politykę keep-alive wplatformach carbon-aware FaaS}. Jednocześnie empirycznie walidujemy domyślną wartość $\lambda =0,2$ przyjętą w~LACE-RL bez eksperymentalnego uzasadnienia — co jest samodzielnym wkładem metodologicznym.

TOPSIS igranice przewagi modeli energetycznych. Rozbieżność modelu TOPSIS ($16,7$) jest niższa od zakładanego progu$30$, co sugeruje, że dla badanego zestawu workloadów minimalizacja latencji i minimalizacja energii prowadzą do zbliżonych rekomendacji runtimeów. Wynik jest spójny zsilną korelacją między energią alatencją zaobserwowaną przez Pereira et al.⁴ — choć autorzy ci operowali na poziomie języków programowania, anie runtimeów. Wyjątkiem jest Mixed REST, gdzie TOPSIS preferuje Bun (lepszy energetycznie o~$12$ przy porównywalnej latencji) zamiast Deno. Implikacja: analiza wielokryterialna jest przydatna wsytuacjach remisu latencji, gdzie dodatkowy wymiar energetyczny może przesądzić owyborze.

Implikacje Praktyczne

Na podstawie wyników formułujemy następujące rekomendacje dla inżynierów projektujących funkcje serverless:

• Dla workloadów I/O-bound (HTTP, plik, baza danych): Bun jest zdecydowanym liderem energetycznym ($-74$ vs Node.js). Migracja istniejących funkcji Node.js obsługujących ruch API do Bun może przynieść znaczące oszczędności energetyczne — warunkiem jest kompatybilność z~WinterTC API (Bun nie wspiera pełnego ekosystemu npm dla pakietów natywnych).

• Dla workloadów SSR (Next.js, Nuxt.js): Node.js pozostaje optymalnym wyborem energetycznym. Popularne rekomendacje migracji do Bun oparte na benchmarkach wydajnościowych nie przekładają się na oszczędności energetyczne w~tej kategorii.

• Dla funkcji wywołanych rzadko ($N<100$ wywołań per instancja): Bun minimalizuje energetyczny overhead zimnego startu ($-48$ vs Node.js) oraz osiąga plateau JIT szybciej. Jest to istotne dla funkcji harmonogramowych, webhooków i~rzadkich operacji backendowych.

• Dla obliczeń pamięciocentrycznych: Deno oferuje $17$ oszczędności vs Node.js — wybór istotny dla funkcji przetwarzających duże struktury danych.

• Dla platform carbon-aware z~polityką keep-alive: wszystkie trzy środowiska uruchomieniowe mają identyczny ${\lambda }_{idle}\approx 0,20$, więc wybór środowiska uruchomieniowego nie wpływa na optymalny TTL — decyzja ta powinna być oparta wyłącznie na charakterystyce ruchu (rozkład czasu między żądaniami).

Zperspektywy platform operatorów (AWS, GCP, Cloudflare): wyniki sugerują, że oferowanie Bun jako domyślnego środowiska uruchomieniowego dla nowych funkcji I/O-bound mogłoby zmniejszyć ślad węglowy infrastruktury FaaS bez zmiany kodu użytkownika — oile workload nie zawiera intensywnych operacji SSR.

Ograniczenia Badania

Niniejsze badanie jest objęte kilkoma ograniczeniami, które należy uwzględnić przy interpretacji i~uogólnianiu wyników.

Walidacja cross-platform — dwie mikroarchitektury x86-64. Eksperymenty powtórzono na drugiej platformie: Intel Xeon E-2176G (Coffee Lake, 8.generacja, 2018, TDP80W). Wyniki walidacji (Sekcja[→]) potwierdzają, że rankingi są w 100% stabilne (6/6 workloadów identycznych). Proporcje energetyczne między runtimeami różnią się omniej niż3p.p. między platformami, copotwierdza generalizowalność wyników na klasy platform x86-64 server-grade. Wartości bezwzględne energii [J] są wyższe na P2 proporcjonalnie do różnicy TDP ($+23$: 80W vs 65W), co jest zgodne zoczekiwaniami. Platforma P2 udostępnia dodatkowo domenę RAPL DRAM — jej udział $14$–$22$ energii pakietu potwierdza, że brak tej domeny na P1 mógł niedoszacowywać całkowitego kosztu workloadów memory-bound otę wartość. Ograniczeniem pozostaje brak walidacji na platformach ARM (Apple M-series, Ampere Altra), gdzie hierarchia V8 vs JavaScriptCore może być odmienna zewzględu na inną implementację pamięci podręcznej ibrak RAPL~—~wymaga alternatywnych narzędzi pomiarowych (PMU, perf-power).

Domena RAPL DRAM — częściowo zmierzona. Platforma P1 (i7-6700, Skylake) nie eksponuje osobnego licznika energii pamięci (domena intel-rapl:0:2/DRAM), co może niedoszacowywać bezwzględnych wartości energii dla workloadów memory-bound. Platforma P2 (E-2176G, Coffee Lake) udostępnia tę domenę — zmierzone $14$–$22$ energii pakietu pochodzi zDRAM, ajej profil między runtimeami jest zbliżony. Rankingi P1 iP2 są tożsame, co wskazuje, że brak DRAM na P1 nie wpływa na kolejność runtimeów. Ograniczeniem pozostaje brak pomiaru energii karty sieciowej idysku NVMe w~czasie workloadów I/O.

Workloady syntetyczne ibrak ruchu sieciowego. Zdefiniowane workloady są implementacjami syntetycznymi reprezentującymi wzorce serverless, lecz nie odzwierciedlają złożoności produkcyjnych aplikacji (zależności npm, middleware, bazy danych zewnętrzne). Pomiar obejmuje wyłącznie energię CPU — nie uwzględnia zużycia energii przez kartę sieciową, dyski NVMe (dla workloadów I/O) ani przełączniki sieciowe, co prowadzi do niedoszacowania całkowitego kosztu energetycznego dla scenariuszy I/O-intensywnych. Werner et al.⁵ wskazują, że komponenty sieciowe mogą odpowiadać za 10–30% całkowitej energii wworkloadach I/O-bound wśrodowisku chmurowym.

Brak testowania pod obciążeniem współbieżnym. Eksperymenty mierzą energię izolowanej instancji runtimeu obsługującego sekwencyjne żądania. Środowiska FaaS działają wtrybie multi-tenant, gdzie wiele instancji runtimeów dzieli zasoby CPU. Rehman et al.⁶ wykazali wmodelu FaasMeter, że marginal energy pod obciążeniem współbieżnym może istotnie różnić się od energii mierzonej izolowanie — szczególnie dla runtimeów oróżnych strategiach zarządzania wątkami (libuv vs Tokio vs JavaScriptCore GC threads).

Jedna wersja każdego środowiska uruchomieniowego. Przetestowano pojedyncze wersje: Node.js v24.15.0, Deno 2.8.1, Bun 1.3.14. Ekosystem runtimeów JS ewoluuje szybko — wyniki mogą ulec zmianie wraz znową wersją silnika (np. nowy tier JIT wV8 lub optymalizacja JavaScriptCore dla ARM).

Kierunki Przyszłych Badań

Walidacja na platformie ARM. Niniejsza praca zwalidowała wyniki na dwóch mikroarchitekturach x86-64 (Skylake iCoffee Lake), potwierdzając 100% stabilność rankingów (Sekcja[→]). Otwartym pytaniem pozostaje generalizowalność na architekturę ARM (Ampere Altra, AWS Graviton3, Apple M-series), gdzie hierarchia V8 vs JavaScriptCore może być odmienna ze względu na inne charakterystyki pamięci podręcznej iimplementacje pipelinu instrukcji. Architektura ARM wymaga narzędzi innych niż RAPL — liczniki PMU dostępne przez perf-power lub narzędzie EnergyScope⁷. Hipoteza do zbadania: czy przewaga Bun przy I/O-bound wynika zmodelu wywołań systemowych (niezależnego od ISA) czy zoptymalizacji JavaScriptCore specyficznych dla AArch64.

Workloady HTTP pod obciążeniem imarginal energy. Przyszłe badania powinny zastosować metodologię FaasMeter⁶ do pomiaru marginal energy attribution dla $N\in 1,2,4,8,16$ współbieżnych instancji. Hipoteza: Bun dzięki uproszczonemu modelowi wątkowości osiągnie niższy narzut marginalny energii niż Node.js (wielowątkowy libuv zshared event loop). Eksperyment wymaga narzędzia do generowania obciążenia HTTP (wrk2, autocannon) zsynchronizowanego zpomiarem RAPL.

Runtimes edge iWebAssembly. Wyniki bazowe dla Bun/Deno/Node.js powinny być uzupełnione ośrodowiska edge: Cloudflare Workers (V8 Isolates), WinterJS (SpiderMonkey/WASM), oraz moduły WebAssembly uruchamiane wWasmtime⁸. De Macedo et al.² wykazali, że Wasm zużywa o20–30% mniej energii niż równoważny JavaScript w~V8 — porównanie to wymaga rozszerzenia na Bun/Deno oraz scenariusze serverless.

Ślad węglowy iświadomość carbon-aware. Przeliczenie wyników energetycznych na emisję CO${}_2$ wymaga danych ointensywności węglowej sieci elektrycznej centrum danych (grid carbon intensity), dostępnych przez API Electricity Maps lubWattTime. GreenCourier⁹ wykazał $12$ redukcję CO${}_2$ przez harmonogramowanie temporalne — podobna analiza dla wyboru środowiska uruchomieniowego umożliwiłaby bezpośrednie porównanie tych dwóch strategii redukcji emisji.

Worker threads iparalelizm. Node.js worker_threads, Deno workers iBun threads oferują różne modele przetwarzania równoległego~¹⁰. Przyszłe eksperymenty powinny zbadać, jak podział workloadu na wiele wątków wpływa na zużycie energii — szczególnie dla runtimeów zróżnymi strategiami izolacji GC (shared heap vs per-worker heap wDeno).

---

Bibliografia

Footnotes

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

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

3. 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. ↩

4. 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). ↩

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

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

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

8. 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). ↩

9. 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. ↩

10. Kiener, Schirner (2021). Intra-Process Worker Thread Communication for Node.js, Deno and Bun: A Comparative Study. Proceedings of the 2021 IEEE Workshop on Parallel and Distributed Scientific and Engineering Computing (PDSEC). ↩