Wnioski

Niniejsza praca podjęła kwestię energetycznej efektywności środowisk uruchomieniowych JavaScript wkontekście serverless — obszar dotychczas niezbadany empirycznie, mimo rosnącego znaczenia energooszczędności infrastruktury chmurowej. Zaprojektowaliśmy iprzeprowadziliśmy sześć kontrolowanych eksperymentów na dwóch niezależnych platformach bare-metal (P1: Intel Core i7-6700/Skylake; P2: Intel Xeon E-2176G/Coffee Lake; pomiar via RAPL sysfs), gromadząc $n=2\times 900=1800$ pomiarów głównych i~$n=1200$ pomiarów dla analizy skalowalności JIT. Poniżej podsumowujemy odpowiedzi na pytania badawcze oraz wkłady, które ta praca wnosi do dziedziny.

Odpowiedzi na Pytania Badawcze

RQ1 — Metodologia pomiarowa. Opracowany protokół wykazał, że rzetelny pomiar energii JS runtimeów wymaga conajmniej $N_{warm-up}=30$ iteracji rozgrzewki JIT (wyżej niż sugerowane $5$–$15$ wliteraturze dla mikro-benchmarków) oraz stosowania filtru IQR$\times 1,5$ doeliminacji skoków GC. Wpływ skoków GC na medianę energii wyniósł $\le 0,1$ dla badanych workloadów, potwierdzając, że standardowe odśmiecanie pamięci nie wprowadza istotnego szumu pomiarowego przy izolowanych benchmarkach bez długożyjących alokacji. Współczynnik zmienności (CV) poniżej $5$ dla $17$ z$18$ konfiguracji potwierdza wysoką powtarzalność protokołu.

RQ2 — Czy alternatywne środowiska uruchomieniowe są energetycznie efektywniejsze od Node.js? Tak — ale odpowiedź jest zależna od kategorii workloadu. Bun zużywa o~$74$ mniej energii od Node.js przy workloadach I/O-bound io$32$ mniej przy CPU-bound. Deno osiąga $17$ oszczędność przy workloadach memory-bound. Jedyną kategorią, wktórej Node.js jest liderem energetycznym, jest renderowanie po stronie serwera (SSR), gdzie V8/Turbofan dysponuje dojrzałymi specjalizacjami dla operacji naciągach znakowych ($-16$ vs Bun). Wszystkie pary (runtime, workload) wykazują istotność statystyczną na poziomie $p<0,001$ (test Manna-Whitneya) z~dużą wielkością efektu ($d\ge 1,4$, Cohen).

RQ3 — Jakie cechy workloadu determinują wybór optymalnego środowiska uruchomieniowego? Kluczowym wyznacznikiem jest charakter operacji dominujących wworkloadzie. Workloady I/O-bound preferują Bun ze względu na eliminację narzutu libuv przez natywne wywołania systemowe. Workloady memory-bound preferują Deno dzięki agresywniejszej kompilacji Maglev/Turbofan dla stabilnych struktur danych. Workloady SSR (string-intensywne) preferują Node.js ze względu na dojrzałość specjalizacji Turbofan. Workloady CPU-bound iCold Start preferują Bun z~uwagi na krótszy czas osiągania plateau JIT ($N\approx 100$ vs $N\approx 500$ dla V8).

RQ4 — Amortyzacja JIT adecyzje outrzymaniu ciepłej instancji. Próg amortyzacji JIT dla V8 (Node.js, Deno) wynosi $N\approx 500$ wywołań — poniżej tej granicy energia per wywołanie jest nawet $4\times$ wyższa niż w~stanie steady-state. Bun/JavaScriptCore osiąga plateau wcześniej ($N\approx 100$), co czyni go bardziej przewidywalnym energetycznie dla funkcji FaaS wywoływanych rzadko. Wynik ten uzupełnia model LACE-RL Sun et al. (2026), pokazując, że parametr energetyczny per runtime nie jest stały, lecz silnie zależny od liczby wywołań per instancja.

RQ5 — Wielokryterialny model decyzyjny. Model TOPSIS ($E\times L\times C$) wykazał $16,7$ rozbieżność zrankingiem opartym wyłącznie na latencji: dla kategorii Mixed REST preferuje Bun (lepszy energetycznie o$12$ przy porównywalnej latencji) zamiast Deno. Analiza wrażliwości potwierdza stabilność rekomendacji przy zmianach wag wzakresie $\pm 30$. Jednorodność ${\lambda }_{idle}\approx 0,20$ dla wszystkich trzech runtimeów empirycznie waliduje domyślny parametr modelu LACE-RL iwskazuje, że wybór środowiska uruchomieniowego nie powinien wpływać na politykę keep-alive w~platformach carbon-aware FaaS.

RQ6 — Stabilność rankingów między mikroarchitekturami. Powtórzenie eksperymentu JE-EXP-1 na platformie P2 (Intel Xeon E-2176G, Coffee Lake) potwierdziło 100% stabilność rankingów — wszystkie 6z6workloadów wykazuje identyczną kolejność runtimeów na obu platformach. Wartości bezwzględne energii[J] są wyższe na P2 proporcjonalnie do TDP ($\approx +35$), lecz proporcje między runtimeami różnią się omniej niż $3$punkty procentowe. Wynik potwierdza generalizowalność wniosków zP1 na klasy platform x86-64 server-grade iuzasadnia ich użycie jako wytycznych dla operatorów platform FaaS niezależnie od konkretnej generacji CPU.

Wkłady Badawcze

• Protokół pomiarowy dla JS runtimeów — standaryzowana procedura pomiaru energii uwzględniająca warm-up JIT ($N_{warm-up}=30$) ifiltrowanie skoków GC (IQR $\times$ 1{,}5); stanowi metodologiczną podstawę dla przyszłych badań energetycznych nad JavaScript wdowolnym środowisku.

• \textbf{Pierwsza empiryczna analiza energetyczna Node.js, Deno iBun nadwóch platformach sprzętowych} — systematyczny eksperyment na dwóch serwerach bare-metal zpomiarem RAPL (P1: i7-6700/Skylake; P2: Xeon E-2176G/Coffee Lake), obejmujący 6kategorii workloadów $\times$ 50 powtórzeń per konfiguracja ($n=1800$ pomiarów). Rankingi są 100% stabilne (6/6 workloadów) między mikroarchitekturami. Wyniki falsyfikują hipotezę oliniowej korelacji ranking wydajnościowy $\approx$ ranking energetyczny — przewaga energetyczna Bun ($74$) przy I/O-bound jest proporcjonalnie większa niż wydajnościowa ($41$), aNode.js jest liderem energetycznym przy SSR mimo gorszych wyników w~benchmarkach throughputu.

• Analiza amortyzacji JIT dla platform FaaS — empiryczne wyznaczenie progu $N\approx 500$ dla V8 i~$N\approx 100$ dla JavaScriptCore, zbezpośrednią implikacją dla strategii keep-alive wniskoruchu serverless.

• Empiryczna walidacja parametru LACE-RL — potwierdzenie ${\lambda }_{idle}\approx 0,20$ dla wszystkich trzech runtimeów, costanowi samodzielny wkład metodologiczny uzupełniający model carbon-aware FaaS oeksperymenty empiryczne.

• Model TOPSIS dla wyboru środowiska uruchomieniowego — wielokryterialny ranking środowisk uruchomieniowych JavaScript uwzględniający energię, latencję iszacunkowy koszt operacyjny, zanalizą wrażliwości wag i~interpretacją dla inżynierów platform serverless.

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

Ograniczenia i~Kierunki Przyszłych Badań

Praca obejmuje dwie mikroarchitektury x86-64 (Skylake i~Coffee Lake), potwierdzając stabilność rankingów. Uogólnienie na architektury ARM (Apple M-series, Ampere Altra) oraz nowsze mikroarchitektury Intel (Raptor Lake, Sapphire Rapids) wymaga jednak dalszej walidacji — stanowi to priorytetowy kierunek przyszłych badań. Pomiar DRAM był dostępny tylko na P2 (E-2176G): domena RAPL PP1/DRAM niedostępna na i7-6700 może niedoszacowywać przewagi Deno przy workloadach pamięciocentrycznych na P1, choć rankingi obu platform są tożsame.

Spośród kierunków badań wyróżnionych wSekcji[→] zanajbardziej obiecujące uznajemy: (1)replikację na platformie ARM (Ampere Altra) zlicznikiem PMU, weryfikującą czy przewaga Bun przy I/O wynika ze specyfiki x86 czy architektury JavaScriptCore; oraz (2)zastosowanie metodologii FaasMeter¹ dopomiaru marginal energy pod obciążeniem współbieżnym, który lepiej odzwierciedla rzeczywiste warunki platform multi-tenant.

Podsumowanie

Badanie pokazuje, że wybór środowiska uruchomieniowego JavaScript ma wymierny iistotny statystycznie wpływ na zużycie energii wkontekście serverless — różnice sięgają $74$ między najlepszym anajgorszym runtimem przy workloadach I/O-bound. Jednocześnie wyniki obalają uproszczone podejście „zamień Node.js na Bun aby zaoszczędzić energię”: dla aplikacji SSR taka migracja może zwiększyć zużycie energii. Inżynierowie ioperatorzy platform powinni przeprowadzać analizę charakterystyki workloadu przed podjęciem decyzji owyborze środowiska uruchomieniowego — aniniejsza praca dostarcza zarówno metodologii pomiaru, jak iempirycznych danych dowsparcia tej decyzji.

---

Bibliografia

Footnotes

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