Wstęp

Obliczenia bezserwerowe (serverless) stały się jednym z dominujących paradygmatów wdrażania aplikacji w chmurze. Szacuje się, że rynek FaaS (Function as a Service) przekroczy 17 miliardów USD do 2028 roku, a globalne zużycie energii przez centra danych odpowiada już za 1–2% światowej konsumpcji elektryczności~¹. W tej sytuacji efektywność energetyczna środowisk uruchomieniowych nabiera znaczenia zarówno operacyjnego — jako bezpośredni składnik kosztów infrastruktury — jak i środowiskowego, w kontekście celów zeroemisyjności stawianych przez AWS, Google i Microsoft na lata 2030–2040~².

JavaScript (realizowany przez Node.js) jest najczęściej wykorzystywanym językiem w platformach FaaS: AWS Lambda, Google Cloud Functions i Cloudflare Workers domyślnie obsługują Node.js jako środowisko wykonawcze. Stan ten wynika z unikalnych właściwości modelu wykonania JavaScript — pętla zdarzeń (event loop) i nieblokujące wejście/wyjście minimalizują narzut per-żądanie dla reaktywnych workloadów I/O-bound, typowych dla funkcji serverless. Według State of JavaScript 2024, Node.js używa 90{,}8% programistów, Bun — 16{,}4%, a Deno — 11{,}8%~³.

Ekosystem środowisk uruchomieniowych JavaScript przechodzi fundamentalną zmianę: obok dojrzałego Node.js (V8, 2009) pojawiły się Deno (V8 + Rust/Tokio, 2020) i Bun (JavaScriptCore, 2022), deklarujące znaczną poprawę wydajności. Laakso~³ wykazał, że Bun osiąga 103,k,req/s vs 73,k,req/s dla Node.js w testach natywnego API HTTP, a czas zimnego startu (cold start) Bun jest 3$\times$ krótszy niż Node.js. Smirnov et al.⁴ przeprowadzili systematyczne porównanie wydajnościowe trzech runtimeów, jednak żadna z tych prac nie mierzy zużycia energii. Pereira et al.⁵⁶ ustalili hierarchię efektywności energetycznej 27 języków programowania, traktując jednak JavaScript monolitycznie — jako jeden runtime (Node.js). De Macedo et al.~⁷ porównali WebAssembly z JavaScript w kontekście energetycznym, lecz ograniczyli się do Node.js i środowisk non-serverless. Luka badawcza jest zatem jednoznaczna: \textbf{nikt nie zmierzył różnic energetycznych między Node.js, Deno i Bun w workloadach serverless.}

Wypełnienie tej luki wymaga rozwiązania problemu metodologicznego. Standardowe podejście do pomiaru energii programów~⁵ nie uwzględnia specyfiki środowisk uruchomieniowych JavaScript: kompilacji JIT (Just-In-Time) wymagającej rozgrzewki (warm-up) przed stabilizacją zużycia energii, przerw wywołanych przez odśmiecanie pamięci (garbage collection, GC), oraz różnicy między izolowanym benchmarkiem a rzeczywistym scenariuszem wielofunkcyjnym (multi-tenant FaaS). Albonico et al.⁸ zaproponowali wzorzec eksperymentalny dla energetycznych badań porównawczych języków (różne obciążenia $\times$ różne konfiguracje), a Werner et al.⁹ zdefiniowali siedmiowymiarową przestrzeń kontroli zmiennych dla chmurowych eksperymentów energetycznych (framework CLUE). Brak jednak protokołu uwzględniającego specyfikę JIT i GC dla pomiarów JS runtimeów.

Niniejsza praca stawia następujące pytania badawcze:

• RQ1: Jak zmierzyć zużycie energii środowisk uruchomieniowych JavaScript w sposób powtarzalny i porównywalny — z uwzględnieniem warm-up JIT i przerw GC?
• RQ2: Czy Deno i Bun są energetycznie efektywniejsze od Node.js dla typowych serverless workloadów (CPU-bound, I/O-bound, mixed, cold start)?
• RQ3: Jakie cechy workloadu determinują wybór energetycznie optymalnego środowiska uruchomieniowego JavaScript?
• RQ4: Jak przebiega amortyzacja JIT w funkcji liczby wywołań i jaki jest empiryczny parametr mocy spoczynkowej ${\lambda }_{idle}$ dla każdego środowiska uruchomieniowego — z bezpośrednimi implikacjami dla strategii keep-alive w platformach FaaS?
• RQ5: Jak zbudować praktyczny wielokryterialny model decyzyjny (energia $\times$ latencja $\times$ koszt) dla inżynierów dobierających runtime do workloadów serverless?
• RQ6: Czy rankingi energetyczne są stabilne między mikroarchitekturami x86-64 — i tym samym generalizowalne poza pojedynczą platformę sprzętową?

Wkłady badawcze niniejszej pracy są następujące:

• Protokół pomiarowy dla JS runtimeów: standaryzowana procedura pomiaru energii uwzględniająca warm-up JIT i filtrowanie skoków GC (IQR $\times$ 1{,}5), stanowiąca metodologiczną podstawę dla przyszłych badań energetycznych nad JavaScript. Eksperyment wykazał, że minimalne $N_{warm-up}=30$ iteracji jest wymagane dla stabilizacji pomiarów V8 i JavaScriptCore, a wpływ skoków GC na medianę energii wynosi $\le 0,1$ dla badanych workloadów.

• \textbf{Pierwsza empiryczna analiza energetyczna Node.js, Deno i Bun na dwóch platformach}: systematyczne eksperymenty na dwóch dedykowanych serwerach bare-metal (P1: Intel Core i7-6700/Skylake, P2: Intel Xeon E-2176G/Coffee Lake; pomiar via Intel RAPL sysfs), obejmujące 6 kategorii workloadów serverless $\times$ 50 powtórzeń ($n=2\times 900=1800$ pomiarów). Bun zużywa o~$74$ mniej energii od Node.js przy workloadach I/O-bound io$32$ mniej przy CPU-bound; jedyną kategorią, wktórej Node.js jest liderem, jest SSR($-11$–$16$ vs Bun). Rankingi są 100% stabilne (6/6 workloadów) między mikroarchitekturami.

• Analiza amortyzacji JIT i walidacja parametru LACE-RL: empiryczne wyznaczenie progu amortyzacji JIT na poziomie $N\approx 500$ wywołań dla V8 i~$N\approx 100$ dla JavaScriptCore, zbezpośrednią implikacją dla polityki keep-alive wniskoruchu serverless. Wyznaczony ${\lambda }_{idle}\approx 0,20$ jest identyczny dla wszystkich trzech runtimeów, empirycznie walidując domyślne założenie modelu LACE-RL~¹⁰.

• Model decyzyjny TOPSIS: wielokryterialny ranking środowisk uruchomieniowych JavaScript uwzględniający energię, latencję i koszt ($E\times L\times C$) z analizą wrażliwości wag. Model wykazuje, że optymalizacja wyłącznie latencji prowadzi do energetycznie suboptymalnego wyboru w $16,7$ kategorii workloadów.

• Publiczny benchmark suite: otwarty zestaw workloadów i skryptów pomiarowych dostępny publicznie (https://github.com/kamilwa/js-runtime-energy, licencja MIT) umożliwiający reprodukcję wyników i rozszerzenie o kolejne środowiska uruchomieniowe (np. WinterJS, Cloudflare Workers).

Artykuł jest zorganizowany w następujący sposób: Sekcja~[→] omawia stan wiedzy w zakresie efektywności energetycznej języków programowania, narzędzi pomiarowych i środowisk serverless. Sekcja~[→] opisuje protokół pomiarowy, środowisko eksperymentalne i projektowanie eksperymentów. Sekcja~[→] przedstawia wyniki empiryczne i odpowiedzi na pytania badawcze. Sekcja~[→] interpretuje wyniki, omawia ograniczenia i implikacje praktyczne. Sekcja~[→] podsumowuje wkłady i wskazuje kierunki przyszłych badań.

---

Bibliografia

Footnotes

1. Andrae (2020). New Perspectives on Internet Electricity Use in 2030. Engineering and Applied Science Letters, vol. 3, pp. 19—31. ↩

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

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

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

5. 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). ↩ ↩²

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

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

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

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

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