Wyniki

Niniejsza sekcja przedstawia wyniki eksperymentów przeprowadzonych na \textbf{dwóch niezależnych platformach sprzętowych}: P1~— Intel Core i7-6700 (Skylake, 2015, Ubuntu 24.04.4 LTS) oraz P2~— Intel Xeon E-2176G (Coffee Lake, 2018, Ubuntu 24.04.3 LTS). Obie platformy użyły identycznych wersji runtimeów (Node.jsv24.15.0, Deno2.8.1, Bun1.3.14) i identycznego protokołu pomiarowego: $n=50$ powtórzeń per konfiguracja po30 iteracjach rozgrzewki. Platforma P2 dodatkowo eksponuje domenę RAPL DRAM (intel-rapl:0:2), niedostępną na P1. Łącznie zebrano $2\times 900=1800$ pomiarów głównych. Sekcja zorganizowana jest według pytań badawczych: RQ1 ([→]), RQ2–RQ3 ([→]), RQ4 ([→]), RQ5 ([→]), RQ6 — walidacja cross-platform ([→]).

RQ1: Protokół Pomiaru Energii — Warm-up JIT i Skoki GC

Eksperyment JE-EXP-2 zbadał wpływ rozgrzewki JIT na stabilność pomiarów energii, mierząc 100 kolejnych wywołań workloadu CPU-bound (SHA-256 hashing) bez restartu procesu.

\centering \small Wyniki protokołu warm-up JIT (#JE-EXP-2). $N_{\text{warm-up iteracji do stabilizacji energetycznej; GC — liczba wykrytych skoków; GC~[%] — procentowy wpływ na medianę bez filtrowania.}

---

| Runtime | $N_{warm-up}$ | Wykryte skoki GC | Wpływ GC na medianę [%] |

| Node.js v24.15.0 | 30 | 5 | 0{,}1 | | Deno 2.8.1 | 30 | 3 | 0{,}0 | | Bun 1.3.14 | 30 | 5 | 0{,}0 |

Wyniki (Tabela~[→]) wskazują, że wszystkie trzy środowiska uruchomieniowe wymagają~$N_{warm-up}=30$ iteracji przed stabilizacją zużycia energii. Jest to wartość wyższa niż sugerowane w literaturze $N=5$–$15$ dla V8 w warunkach mikro-benchmarków~¹, co wynika z faktu, że workload SHA-256 z buforem 64~KB aktywuje wyższy poziom optymalizacji JIT (Turbofan tier) dopiero po wielokrotnym wykonaniu. Wpływ skoków GC na medianę energii jest znikomy ($\le 0,1$) dla wszystkich runtimeów — co wskazuje na niski poziom presji na Garbage Collector przy izolowanym workloadzie bez alokacji długożyjących obiektów.

Odpowiedź na RQ1: Rzetelny pomiar energii JS runtimeów wymaga co najmniej $N_{warm-up}=30$ iteracji rozgrzewania dla V8 (Node.js, Deno) i JavaScriptCore (Bun) przy workloadach intensywnych obliczeniowo. Wpływ skoków GC jest pomijalny dla badanych workloadów, ale protokół filtrowania (IQR~$\times 1,5$) pozostaje rekomendowany jako środek ostrożności dla workloadów z dużą alokacją obiektów.

RQ2–RQ3: Porównanie Energetyczne Node.js, Deno i Bun

Eksperyment JE-EXP-1 zmierzył zużycie energii pakietu CPU (domena RAPL Package) dla 6kategorii workloadów serverless przy 50 powtórzeniach per konfiguracja. Domena PP0 Core stanowiła konsekwentnie $91,5$–$93,4$ energii pakietu we wszystkich konfiguracjach, co wskazuje na dominujący udział rdzeni obliczeniowych; domena Uncore (PP1) zwróciła wartość zerową na badanej platformie(i7-6700, Skylake), ponieważ procesor ten nie eksponuje oddzielnego licznika Uncore w sysfs (intel-rapl:0:1~=0J we wszystkich pomiarach).

\centering \small \caption{Mediana energii pakietu CPU~[J] per workload i runtime (#JE-EXP-1, $n=50$). Pogrubiono wartość minimalną (najlepszą) w każdym wierszu. ${\Delta }_{Bun/Node}$ — różnica względna Bun vs Node.js [%].}

---

| Workload | Node.js~[J] | Deno~[J] | Bun~[J] | ${\Delta }_{Bun/Node}$~[%] |

| CPU-bound | 44{,}05 | 43{,}48 | **29{,**85} | $-32,1$ | | I/O-bound | 17{,}36 | 14{,}07 | **4{,**52} | $-74,0$ | | Mixed REST | 2{,}20 | 1{,}81 | **1{,**59} | $-27,7$ | | Memory | 135{,}37 | **112{,**20} | 133{,}04 | $-1,7$ | | SSR | **1{,**50} | 1{,}62 | 1{,}74 | $+16,3$ | | Cold start | 0{,}60 | 0{,}64 | **0{,**31} | $-48,2$ |

Tabela~[→] zbiera mediany energii dla wszystkich konfiguracji. Wszystkie różnice między parami runtimeów są istotne statystycznie ($p<0,001$, test Mann-Whitney U, $\alpha =0,05$) z dużym rozmiarem efektu (Cohen’s $d\ge 1,4$ dla wszystkich par we wszystkich workloadach). Przy 18konfiguracjach i2testach parami wykonano łącznie 36porównań; korekta Bonferroniego daje próg ${\alpha }^{\prime }=0,05/36\approx 0,0014$, który jest spełniony przez wszystkie pary ($p<0,001\ll {\alpha }^{\prime }$), co potwierdza robustność wniosków wobec wielokrotnych porównań.

Workload CPU-bound. Bun zużył $29,85$J mediany energii pakietu, co stanowi redukcję o$32$ względem Node.js ($44,05$J) i$31$ względem Deno ($43,48$~J). Różnica między Node.js a Deno jest mniejsza — wynosi $1,3$ — i jest statystycznie istotna ($d=1,46$), lecz nieistotna praktycznie. Wynik potwierdza hipotezę H1: JavaScriptCore (Bun) jest energetycznie bardziej efektywny niż V8 (Node.js, Deno) dla synchronicznych workloadów obliczeniowych.

Workload I/O-bound. Najsilniejsza z obserwowanych różnic: Bun zużył $4,52$J, czyli o$74$ mniej niż Node.js ($17,36$J) i $68$ mniej niż Deno ($14,07$J). Deno z kolei jest o$19$ lepszy od Node.js ($d=10,2$). Tak duże różnice przy workloadzie I/O-bound wskazują, że implementacja asynchronicznego we/wy przez JavaScriptCore+~natywne API systemowe w Bun jest energetycznie znacznie efektywniejsza niż warstwa libuv w Node.js, zaś asynchroniczny runtime Tokio/Rust w Deno osiąga pośredni wynik.

Workload Memory-bound. Wynik odbiega od ogólnego trendu: Deno ($112,20$J) jest o$17$ lepszy od Node.js ($135,37$~J), natomiast Bun ($133,04$~J) jest porównywalny do Node.js ($d=1,4$, różnica $1,7$). Wynik sugeruje, że implementacja operacji na dużych tablicach w V8 (Node.js, Deno) wykazuje zróżnicowaną efektywność: Deno korzysta prawdopodobnie z agresywniejszych optymalizacji JIT dla operacji tablicowych przy długich sesjach, podczas gdy Bun nie uzyskuje tutaj przewagi JavaScriptCore.

Workload SSR. Jedyna kategoria, w której Node.js jest liderem energetycznym: $1,50$~J vs $1,62$J (Deno, $+8$) vs $1,74$J (Bun, $+16$). Workload SSR obejmuje renderowanie szablonów zintensywnym przetwarzaniem ciągów znakowych, w którym silnik V8 (Node.js) osiąga przewagę nad JavaScriptCore przy długich łańcuchach transformacji — co koresponduje z wynikami benchmarków wydajnościowych Laakso².

Cold start. Bun zużył $0,31$J na zimny start — o$48$ mniej niż Node.js ($0,60$J) i$52$ mniej niż Deno ($0,64$~J). Niższa energia zimnego startu Bun wynika z krótszego czasu inicjalizacji silnika JavaScriptCore w trybie AOT (Ahead-of-Time baseline JIT).

\centering figures/exp1_energy_boxplot.pdf{ \includegraphics[width=\linewidth]{figures/exp1_energy_boxplot}}{ \fbox{0.95\linewidth{\centering \textit{[Rysunek: boxploty energii per (runtime $\times$ workload) — zostanie dodany po generacji wykresów]} }}} \caption{Rozkłady energii pakietu CPU~[J] per (runtime $\times$ workload), $n=50$ powtórzeń. Dolne/górne krawędzie pudełka: Q1/Q3; wąsy: $\pm 1,5\cdot IQR$; krzyżyki: wartości odstające. Wykresy na osi Y są niezależnie skalowane per workload.}

Rysunek~[→] prezentuje rozkłady energii. Niskie IQR ($\le 5,1$~J) i brak nakładania się rozkładów między runtimeami potwierdzają wysoką powtarzalność pomiarów i istotność różnic.

Odpowiedź na RQ2: Bun jest środowiskiem uruchomieniowym o najniższym zużyciu energii dla workloadów CPU-bound ($-32$ vs Node.js), I/O-bound ($-74$), Mixed REST ($-28$) i cold start ($-48$). Deno przewyższa energetycznie Bun wyłącznie przy workloadach memory-bound ($-17$ vs Node.js).

Odpowiedź na RQ3: Typ workloadu determinuje wybór środowiska uruchomieniowego. Nie istnieje środowisko dominujące we wszystkich kategoriach: Bun wygrywa w 4z6kategorii, Node.js w1~(SSR), Deno w1(memory).

RQ4: Amortyzacja JIT — Energia w Funkcji Liczby Iteracji

Eksperyment JE-EXP-4 zbadał energię per iterację w~funkcji rozmiaru zadania (liczby iteracji $N\in 1,5,10,50,100,500,1000,5000$) dla workloadów CPU-bound i Mixed REST, $n=25$ per konfiguracja.

\centering \small \caption{Energia per iterację~[mJ/iter] dla workloadu CPU-bound w funkcji $N$~iteracji (#JE-EXP-4, $n=25$). Pogrubiono wartości dla $N\ge 500$, po stabilizacji JIT.}

---

| $N$ iteracji | Node.js~[mJ/iter] | Deno~[mJ/iter] | Bun~[mJ/iter] |

| 1 | 1017{,}9 | 1128{,}0 | 692{,}0 | | 5 | 211{,}5 | 231{,}9 | 140{,}8 | | 10 | 109{,}4 | 118{,}9 | 73{,}3 | | 50 | 63{,}1 | 67{,}3 | 37{,}7 | | 100 | 55{,}1 | 57{,}0 | 34{,}1 | | 500 | **45{,**1} | **45{,**8} | **30{,**4} | | 1000 | **43{,**7} | **43{,**6} | **30{,**0} | | 5000 | **42{,**0} | **41{,**7} | **29{,**4} |

Tabela~[→] oraz Rysunek~[→] ujawniają wyraźny efekt amortyzacji JIT dla V8~(Node.js, Deno): energia per iterację spada zok. $1000$–$1130$mJ przy $N=1$ do ok.$42$mJ przy $N=5000$ — redukcja o$96$. Plateau efektywności energetycznej osiągane jest wzakresie $N=500$–$1000$ (zmiana między $N=500$ a $N=5000$ wynosi $<8$), co wyznacza \textbf{próg amortyzacji JIT} na poziomie ok.~$500$~wywołań.

\centering figures/exp4_jit_amortisation.pdf{ \includegraphics[width=\linewidth]{figures/exp4_jit_amortisation}}{ \fbox{0.95\linewidth{\centering \textit{[Rysunek: krzywe amortyzacji JIT energia/iter vs N — zostanie dodany po generacji wykresów]} }}} \caption{Energia per iterację~[mJ/iter] w funkcji liczby iteracji~$N$ (skala log) dla workloadów CPU-bound i Mixed REST. Linie pionowe oznaczają próg amortyzacji JIT ($N\approx 500$ dla V8).}

Bun osiąga plateau energetyczne szybciej — już przy $N\approx 100$ (zmiana z~$N=100$ do $N=5000$ wynosi $13$), co wynika z braku wielopoziomowego kompilatora JIT w JavaScriptCore (brak odpowiednika Turbofan). Przy $N=1$ Bun jest o~$32$ i~$39$ efektywniejszy niż odpowiednio Node.js iDeno, natomiast przy $N=5000$ różnica stabilizuje się na$29$–$30$ — zbieżna z wynikami workloadu CPU-bound z~#JE-EXP-1. Wynik ma bezpośrednie implikacje dla środowisk FaaS: funkcje serverless wywoływane rzadziej niż ok.~500 razy per instancja (typowe dla niskiej intensywności ruchu) są energetycznie znacznie droższe dla V8 niż wynikałoby z pomiarów steady-state.

Odpowiedź na RQ4: Próg amortyzacji JIT dla V8 (Node.js, Deno) wynosi $N\approx 500$ wywołań, po którym energia per iterację stabilizuje się wodległości $<8$ od asymptoty. Bun (JavaScriptCore bez Turbofan) osiąga plateau przy $N\approx 100$, ale zachowuje stałą przewagę energetyczną ($29$–$32$) nad V8 niezależnie od$N$.

RQ4 (cd.): Idle Power i Parametry Keep-alive (#JE-EXP-5)

Eksperyment JE-EXP-5 wyznaczył parametry modelu energetycznego keep-alive dla środowisk FaaS: moc w stanie spoczynku $P_{idle}$ i~energię inicjalizacji instancji $E_{cold}$, $n=20$ per konfiguracja.

Uwaga terminologiczna: $E_{cold}$ w tym eksperymencie oznacza całkowity koszt energetyczny uruchomienia ciepłej instancji — obejmuje spawn procesu, załadowanie modułów i~wykonanie $N_{warm-up}=30$ wywołań rozgrzewkowych do ustabilizowania JIT. Wartość ta ($\approx 3,5$J) jest ok.10-krotnie wyższa niż energia pierwszego zimnego żądania HTTP zTab.[→] ($0,31$–$0,64$~J), ponieważ JE-EXP-1 mierzył wyłącznie energię spawnu procesu do pierwszej odpowiedzi HTTP, natomiast $E_{cold}$ w modelu LACE-RL obejmuje pełen koszt doprowadzenia instancji do stanu steady-state JIT.

\centering \small *Parametry energetyczne keep-alive (#JE-EXP-5, $n=20$). P_{\text{idle* mocy przy braku obciążenia~[W]; E_{cold}$—medianaenergiizimnegostartu[J];$\lambda_{idle} = P_{idle} / P_{active}$;$P_{sys} = 3{,}10$~W (baseline systemowy).}

---

| Runtime | $E_{cold}$[J] | $P_{idle}$[W] | $P_{active}$~[W] | ${\lambda }_{idle}$ |

| Node.js v24.15.0 | 3{,}49 | 3{,}05 | 14{,}90 | 0{,}205 | | Deno 2.8.1 | 3{,}58 | 3{,}01 | 14{,}92 | 0{,}202 | | Bun 1.3.14 | 3{,}49 | 3{,}15 | 15{,}31 | 0{,}206 |

| System (brak rt) | — | 3{,}10 | — | — |

Wyniki (Tabela~[→]) ujawniają zaskakującą jednorodność: $P_{idle}$ dla wszystkich trzech runtimeów mieści się w przedziale $3,01$–$3,15$W ijest niemal identyczna z poziomem systemowym ($3,10$~W). Oznacza to, że uruchomiony, ale nieaktywny proces runtimes nie generuje mierzalnego narzutu energetycznego ponad baseline systemu. Współczynnik ${\lambda }_{idle}\approx 0,20$ jest zbieżny z domyślną wartością założoną w modelu LACE-RL ($\lambda =0,2$, Sun et al.~2026), co empirycznie waliduje założenia modelu dla wszystkich trzech badanych runtimeów.

Energia zimnego startu $E_{cold}\approx 3,5$J jest porównywalna dla Node.js iBun, nieco wyższa dla Deno ($3,58$~J). Przy mocy aktywnej $P_{active}\approx 15$~W i $P_{idle}\approx 3$~W, próg amortyzacji zimnego startu (liczba żądań obsługiwana przez ciepłą instancję zamiast zimnego startu, przy założeniu czasu obsługi żądania $T_{req}=1$~s) wynosi $N_{break}=E_{cold}/(P_{active}-P_{idle})/T_{req}\approx 0,3$~żądania, co praktycznie oznacza, że utrzymywanie ciepłej instancji (keep-alive) jest energetycznie korzystne już od pierwszego żądania.

RQ5: Model Decyzyjny TOPSIS — Energia vs Latencja

Eksperyment JE-EXP-3 zastosował model TOPSIS do porównania rekomendacji runtimeów przy optymalizacji energetycznej~($w_E=0,5$, $w_T=0,3$, $w_C=0,2$) z~podejściem latency-only.

\centering \small \caption{Rekomendacje TOPSIS vs latency-only per workload (#JE-EXP-3). Pogrubiono przypadki rozbieżności.}

---

| Workload | TOPSIS (energia $+$ latencja) | Latency-only |

| CPU-bound | Bun | Bun | | I/O-bound | Bun | Bun | | Mixed REST | Bun | Deno | | Memory | Deno | Deno | | SSR | Node.js | Node.js | | Cold start | Bun | Bun |

Model TOPSIS (Tabela~[→]) daje rekomendację odmienną od latency-only w~$1$z$6$ kategorii workloadów ($16,7$): dla workloadu Mixed REST TOPSIS wskazuje Bun (energetycznie tańszy o~$12$), podczas gdy latency-only preferuje Deno (szybszy o~$0$~ms — remis w medianach). Analiza wrażliwości wykazała, że ta rozbieżność jest stabilna: dla każdej badanej kombinacji wag $w_E\in [0,1,0,9]$ odsetek odmiennych rekomendacji wynosi niezmiennie $16,7$, co wskazuje, że rozbieżność wynika ze struktury danych (bardzo zbliżone mediany latencji Bun i Deno przy Mixed REST), a nie z przyjętych wag.

Wynik nie osiągnął zakładanego progu $>30$ różnych rekomendacji sformułowanego whipotezie EXP-3. Świadczy to, że dla badanego zestawu workloadów serverless i dwóch kryteriów (energia, latencja) obydwa podejścia prowadzą do zbieżnych rekomendacji w$5$z$6$ przypadkach. Jest to wynik istotny: optymalizacja wyłącznie latencji prowadzi do energetycznie optymalnego wyboru w~$83$ kategorii — co ogranicza uzasadnienie dla złożonego modelu MCDM w prostych scenariuszach wdrożeniowych, choć nie eliminuje go dla środowisk wielokryterialnych.

Odpowiedź na RQ5: Model TOPSIS z wagami energetycznymi różni się od latency-only w~$16,7$ kategorii workloadów ($1$ z~$6$). Ranking TOPSIS jest stabilny na zmiany wag, adominującym środowiskiem w rankingu wielokryterialnym pozostaje Bun (4z6 workloadów) — identycznie jak woptimizacji latencji.

RQ6: Walidacja Cross-Platform — Stabilność Rankingów

Eksperyment JE-EXP-1 powtórzono wcałości na platformie P2 (Intel Xeon E-2176G, Coffee Lake, 6C/12T, TDP80W). Cel: zweryfikować, czy rankingi energetyczne uzyskane naP1 (Skylake, 4C/8T, TDP65W) są specyficzne dla mikroarchitektury, czy~też odzwierciedlają właściwości silników JS niezależne od sprzętu.

\centering\small \caption{Stabilność rankingów energetycznych między platformami. N~=Node.js, D=Deno, B=~Bun (posortowane rosnąco). ${\Delta }_{best}$ = zmiana mediany lidera: P2 vs P1.}

---

| Workload | Ranking P1 | Ranking P2 | Zgodny | ${\Delta }_{best}$~[%] |

| CPU-bound | B $<$ D $<$ N | B $<$ D $<$ N | \checkmark | $+40,4$ | | I/O-bound | B $<$ D $<$ N | B $<$ D $<$ N | \checkmark | $+31,9$ | | Memory-bound | D $<$ B $<$ N | D $<$ B $<$ N | \checkmark | $+45,6$ | | SSR | N $<$ D $<$ B | N $<$ D $<$ B | \checkmark | $+42,7$ | | Mixed REST | B $<$ D $<$ N | B $<$ D $<$ N | \checkmark | $+29,5$ | | Cold Start | B $<$ N $<$ D | B $<$ N $<$ D | \checkmark | $+41,9$ |

| 3{l}{Ranking zgodny w 6/6 workloadów} | | |

Tabela~[→] pokazuje, że wszystkie sześć rankingów jest identycznych na obu platformach ($100$ stabilność). Wartości bezwzględne energii są wyższe na P2 (${\Delta }_{best}\approx +30$–$46$), co wynika zwyższego TDP procesora (80W vs 65W) iwiększej liczby rdzeni (6C vs 4C). Proporcje między runtimeami zachowują się jednak spójnie: Bun pozostaje liderem energetycznym przy I/O-bound ($-76,6$ vs Node.js na P2, $-74,0$ na P1), a~Node.js przewodzi przy SSR na obu platformach ($-11,3$ vs Bun na P2).

\centering figures/cross_platform_bars.pdf{ \includegraphics[width=\linewidth]{figures/cross_platform_bars}}{ \fbox{0.95\linewidth{\centering \textit{[Rysunek: wykres słupkowy porównania P1 vs P2 — zostanie dodany po generacji wykresów]} }}} \caption{Porównanie median energii pakietu CPU [J] na platformach P1 (i7-6700) i~P2 (E-2176G). Rankingi wewnętrzne (kolejność słupków) identyczne na obu platformach.}

Platforma P2 udostępnia domenę RAPL DRAM (intel-rapl:0:2), niedostępną naP1. Analiza wykazała, że energia DRAM stanowi $14$–$22$ energii pakietu CPU wzależności od workloadu, z~najwyższym udziałem przy operacjach memory-bound ($22$). Potwierdza to, że brak domeny DRAM na P1 mógł prowadzić do niedoszacowania całkowitego kosztu energetycznego workloadów pamięciocentrycznych.

Odpowiedź na RQ6: Rankingi energetyczne Node.js/Deno/Bun są \textbf{w100% stabilne} między mikroarchitekturami Skylake (2015) i Coffee Lake (2018). Wartości bezwzględne skalują się zTDP platformy, lecz proporcje między runtimeami różnią się o~mniej niż $3$ punkty procentowe między platformami, co potwierdza generalizowalność wyników P1 na klasy platformy x86-64.

Podsumowanie Wyników

\centering \small Zbiorcze odpowiedzi na pytania badawcze.

---

| Pytanie badawcze | Odpowiedź |

RQ1 Metodologia pomiaru & $N_{warm-up}=30$ dla V8 i JavaScriptCore; wpływ GC na medianę $<0,1$. \ \addlinespace RQ2 Który runtime jest energetycznie najlepszy? & Bun (4 z 6 workloadów); Node.js najlepszy przy SSR; Deno przy memory-bound. \ \addlinespace RQ3 Zależność od typu workloadu? & Silna: Bun $-74$ vs Node.js przy I/O-bound, ale $+16$ przy SSR. Żaden runtime nie dominuje we wszystkich kategoriach. \ \addlinespace RQ4 Amortyzacja JIT & Próg amortyzacji V8: $N\approx 500$ wywołań. Bun plateau przy $N\approx 100$. Przy $N<50$ różnice między runtimeami odwracają się względem steady-state. \ \addlinespace RQ5 Model decyzyjny & ${\lambda }_{idle}\approx 0,20$ — identyczne dla wszystkich 3 runtimeów. TOPSIS różni się od latency-only w $16,7$ przypadków (workload Mixed REST). \ \addlinespace RQ6 Walidacja cross-platform & Rankingi 100% stabilne (6/6 workloadów) między Skylake (P1) a Coffee Lake (P2). Proporcje między runtimeami różnią się $<3$ p.p. między platformami. \

---

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. Laakso (2025). The Next Generation of Server-Side JavaScript Runtimes: Node.js, Deno and Bun. Turku University of Applied Sciences. ↩