Pomysły badawcze
Ostatnia aktualizacja: 2026-05-25
🔥 Wysokie priorytety
[#JE-1] Pierwsza rygorystyczna analiza energetyczna Node.js vs Deno vs Bun w środowiskach serverless
Status: new Priorytet: high Dodano: 2026-05-25 Bazuje na: Smirnov 2024, Pereira 2017, De Macedo 2022
Gap badawczy:
- Smirnov et al. (2024): porównuje Node.js/Deno/Bun pod kątem czasu — bez wymiaru energetycznego
- Laakso (2025) — szara literatura (praca licencjacka): benchmark wydajnościowy Node.js/Deno/Bun — bez energii; Bun 103k req/s vs Node.js 73k vs Deno 73k (native API) na Apple M2
- Pereira et al. (2017, 2021): rankuje języki energetycznie, ale JavaScript traktuje monolitycznie (jeden runtime = Node.js)
- De Macedo et al. (2022): Wasm vs JS energia, ale nie-serverless i tylko Node.js
- Nikt nie zmierzył różnic energetycznych między runtimeami JS w serverless workloadach
Hipotezy:
- H1: Bun zużywa mniej energii niż Node.js dla synchronicznych zadań CPU-bound (JavaScriptCore < V8 dla JS synchronous execution) — wsparte: Laakso 2025 pokazuje Bun 34% szybszy CPU-bound, sugeruje mniejsze zużycie energii
- H2: Deno jest bardziej efektywny energetycznie niż Node.js dla asynchronicznych operacji I/O (Tokio async runtime w Rust)
- H3: Różnice energetyczne między runtimeami są większe niż różnice czasowe (JIT warm-up energetyczny)
- H4: Dla cold start scenariuszy Bun ma najniższy energetyczny koszt inicjalizacji — Laakso: Bun ~3× szybszy startup
- H5: Różnice energetyczne zależą od workloadu — brak “zawsze najlepszego” runtimes dla wszystkich typów zadań — częściowo potwierdzono: Laakso: Deno > Node.js w JSON, Bun > wszyscy w HTTP; ale brak energii
Proponowane badanie:
- Runtimes: Node.js 22 (LTS), Deno 2.x, Bun 1.x
- Workloady (6 kategorii):
- CPU-bound: sortowanie, hashing SHA256, przetwarzanie JSON (parse/stringify)
- I/O-bound: file read/write, HTTP fetch, database queries (SQLite)
- SSR: renderowanie template (Handlebars, EJS)
- Cold start: czas + energia od spawnu do pierwszego response
- Memory-intensive: large array/object operations
- Mixed: typowy REST API handler (JSON in → compute → JSON out)
- Pomiar: Intel RAPL przez PowerJoular + wall clock time + RSS memory
- Środowisko kontrolowane: bare-metal Intel server (eliminacja hypervisor noise), Ubuntu 24.04
- Protokół: 30 powtórzeń, median + IQR, Mann-Whitney U (p<0.05), warmup 5 iteracji odrzucane
- Analiza: energia × czas × pamięć — 3D ranking jak Pereira 2017
Wkład badawczy:
- Pierwsza praca energetycznie porównująca Node.js/Deno/Bun w serverless workloadach
- Publiczny benchmark suite (GitHub, CI/CD ready)
- Praktyczne rekomendacje: kiedy zmiana runtimes daje oszczędności energetyczne
Metodologia wzorowana na: Pereira 2017/2021 (RAPL + standaryzowane benchmarki) + Albonico 2025 (wielozmiennowy design eksperymentu)
[#JE-2] Model decyzyjny wyboru runtime JS dla architektur serverless i edge: optymalizacja energia–latencja–koszt
Status: new Priorytet: high Dodano: 2026-05-25 Bazuje na: Pereira 2021, Lumos 2025, [JE-1]
Gap badawczy:
- Lumos (2025): model wydajnościowy dla Wasm — brak JS runtimeów, brak energii
- Pereira (2021): narzędzie multi-criteria dla języków — brak kontekstu serverless/edge
- Brak modelu decyzyjnego łączącego energię, latencję, koszt dla wyboru runtime w serverless
Hipotezy:
- H1: Optymalna konfiguracja runtime zależy od co najmniej 3 zmiennych: typ workloadu (CPU/IO), środowisko (serverless/edge), wymagania SLO (latency target)
- H2: Model TOPSIS z wagami energia:latencja:koszt = 0.5:0.3:0.2 jest wystarczającym przybliżeniem dla typowych zastosowań
- H3: Istnieje “sweet spot” konfiguracji runtime+platforma dla każdej kategorii workloadu — model może to przewidzieć z ≥80% trafnością
- H4: Modele decyzyjne uwzględniające energię wybierają inny runtime niż modele oparte wyłącznie na latencji (co najmniej 30% przypadków)
Proponowane badanie:
- Przestrzeń decyzyjna: {Node.js, Deno, Bun, Wasm} × {AWS Lambda, Cloudflare Workers, bare OpenWhisk} × {cold, warm} × {CPU/IO/memory-bound}
- Metryki: energia/request [J], latencja p50/p99 [ms], cold start time [ms], koszty chmury [$/mln req], carbon footprint [gCO₂/req]
- Model:
- Zbieranie danych (#JE-1 + dodatkowe pomiary)
- TOPSIS (Technique for Order of Preference by Similarity to Ideal Solution)
- Analiza wrażliwości: jak zmiana wag wpływa na decyzję?
- Walidacja: 5 case studies z rzeczywistymi aplikacjami (Next.js SSR, REST API, edge middleware, background job, streaming)
Wkład:
- Pierwszy praktyczny decision framework uwzględniający energię dla JS serverless
- Open-source narzędzie (web app lub CLI) dla architektów
- Baza danych benchmark wyników (runtime × workload × platforma)
[#JE-3] Rygorystyczna metodologia pomiaru energii JS runtimeów: standaryzacja i reprodukowalność
Status: new Priorytet: high Dodano: 2026-05-25 Bazuje na: PowerJoular 2022, Pereira 2017, Cunha 2024
Gap badawczy:
- RAPL działa na bare-metal Intel — w chmurze jest niedostępny lub niedokładny
- JIT compilation (V8, JavaScriptCore) powoduje non-stationarity energetyczną: pierwsze wywołania ≠ późniejsze
- GC pauses (Garbage Collection) tworzą nieregularne skoki zużycia energii
- Brak standaryzowanej metodologii specyficznej dla JS runtimeów i środowisk serverless
Hipotezy:
- H1: JIT warm-up w Node.js/Deno (V8) wymaga co najmniej 10-15 iteracji “warm-up” przed stabilizacją zużycia energii
- H2: GC-driven energy spikes w JS runtimeach mają istotny wpływ na medianę energii (>5%) — wymagają specjalnego protokołu
- H3: PowerJoular (RAPL-based) i hardware power meter korelują z R²>0.95 dla Node.js procesów przy CPU-bound workloadach
- H4: Szacunki energetyczne z cloud billing metrics (CPU seconds × TDP) mają błąd >20% wobec RAPL na bare-metal
- H5: Bun (JavaScriptCore) ma krótszy JIT warm-up niż Node.js (V8) — szybciej osiąga stabilne zużycie energii
Proponowane badanie:
- Porównanie metod pomiarowych:
- Intel RAPL (via
perf stat --event=power/energy-pkg/) - PowerJoular (process-level attribution)
- Hardware: Yokogawa WT310 power meter
- Cloud: CPU-seconds × TDP estimate (szacowanie)
- Intel RAPL (via
- Identyfikacja confounders: JIT warm-up (jak wiele iteracji?), GC pauses (jak odfiltrować?), OS scheduler variance
- Protokół eksperymentalny:
- Minimalna liczba powtórzeń (power analysis: δ=10%, α=0.05, β=0.2)
- Procedura warm-up: N iteracji odrzucanych (jak dobrać N?)
- Test na stacjonarność zużycia energii (Ljung-Box test)
- Walidacja: cross-validation między metodami pomiaru
- Framework open-source: CLI tool automatyzujący poprawne pomiary JS runtimeów
Wkład:
- Standaryzowana metodologia pomiaru energii JS runtimeów (wzorzec dla przyszłych badań)
- Analiza confounders specyficznych dla JS (JIT, GC, event loop)
- Open-source benchmarking framework z wbudowanym pomiarem energii
📌 Średnie priorytety
[#JE-4] WebAssembly jako runtime JS w edge computing: analiza energetyczna vs Node.js/Deno/Bun
Status: new Priorytet: medium Dodano: 2026-05-25 Bazuje na: De Macedo 2022, Lumos 2025, Besozzi 2025
Gap: De Macedo (2022) porównuje Wasm vs JS energetycznie, ale tylko w środowisku nie-serverless. Lumos (2025) bada Wasm w edge-cloud ale bez pomiaru energii.
Hipotezy:
- H1: Wasm AoT ma niższy energetyczny koszt cold start niż Node.js (mniejszy image = mniej I/O przy starcie)
- H2: Dla warm workloadów Bun (JavaScriptCore JIT) jest energetycznie porównywalny z Wasm AoT dla CPU-bound zadań
- H3: Wasm interpretowany jest energetycznie droższy niż Node.js dla wszystkich kategorii workloadów (Lumos: 30-55× wolniejszy warm)
- H4: Na resource-constrained edge (RPi 5, Jetson Nano) różnice energetyczne między runtimeami są proporcjonalnie większe niż na server-grade hardware
Proponowane badanie: Wasm (Wasmtime, WasmEdge) vs JS runtimes (Node.js, Deno, Bun) na edge hardware:
- Raspberry Pi 5 (ARM, 8GB) — typowy edge node
- Jetson Nano (ARM + GPU, embedded) — IoT edge
- Pomiar: RAPL (Intel) lub perf energy (ARM) + PowerJoular
Wkład: Pierwsza analiza energetyczna Wasm vs JS na edge hardware, rekomendacje IoT/edge deployment
[#JE-5] Carbon footprint JavaScript ecosystem: npm, bundling, runtime — lifecycle analysis
Status: new Priorytet: medium Dodano: 2026-05-25 Bazuje na: GreenCourier 2023
Gap: GreenCourier optymalizuje scheduling serverless pod kątem carbon intensity regionów. Ale sam JavaScript ecosystem (npm install, bundle, cold start, idle) generuje carbon footprint — nikt tego nie zmierzył.
Hipotezy:
- H1: Faza CI/CD build (npm install + bundle) stanowi >10% całkowitego carbon footprint typowej aplikacji JS serverless
- H2: Bun + pnpm mają o >30% mniejszy carbon footprint fazy install niż npm + Node.js (szybszy install = mniej czasu CPU)
- H3: Next.js (SSR) ma wyższy runtime carbon footprint/request niż Astro (SSG+edge) dla statycznych treści
Proponowane badanie: Lifecycle Carbon Analysis (LCA) JS aplikacji:
- Fazy: development (npm install) + CI/CD build + cold start + warm execution + idle (keep-warm)
- Frameworki: Next.js vs Remix vs Astro vs bare Node.js
- Narzędzie: CodeCarbon lub własny pomiar RAPL × czas
[#JE-6] Cold start energy overhead: energetyczny koszt inicjalizacji JS runtimeów
Status: new Priorytet: medium Dodano: 2026-05-25 Bazuje na: Golec 2024, [JE-1], [JE-3]
Gap: Golec (2024) systematyzuje techniki redukcji cold start latency bez pomiaru kosztu energetycznego. Czy mniejsza latencja cold start = mniejsze zużycie energii? Niekoniecznie — keep-warm pochłania energię idle.
Hipotezy:
- H1: Energetyczny koszt cold start (energia od wywołania do gotowości) jest proporcjonalny do czasu cold start dla danego runtimes
- H2: Keep-warm strategy (periodyczne wywołania) jest energetycznie tańsza niż cold start tylko gdy częstotliwość wywołań >1/5min
- H3: Bun ma najniższy energetyczny koszt cold start (najmniejszy runtime, szybsza inicjalizacja)
- H4: WebAssembly AoT ma 2× niższy energetyczny koszt cold start niż Node.js (Lumos: 16% niższy cold start latency → zakładamy proporcjonalność)
Proponowane badanie:
- Pomiar: energia od spawn procesu do pierwszego zhandlowanego requestu (integracja mocy × czas)
- Runtimes: Node.js, Deno, Bun, Wasm (Wasmtime)
- Porównanie strategii: cold vs keep-warm vs pre-warming — total energy over 24h simulation
💡 Niskie priorytety / Backlog
[#JE-7] Serverless function scheduling z runtime awareness: rozszerzenie GreenCourier
Status: new Priorytet: low Dodano: 2026-05-25 Bazuje na: GreenCourier 2023
GreenCourier (2023) optymalizuje geograficznie (carbon intensity regionów). Rozszerzenie: uwzględnienie runtime energy efficiency przy schedulingu — schedule na Bun-node zamiast Node.js-node jeśli workload jest CPU-bound.
Hipoteza: Runtime-aware + region-aware scheduling może redukować carbon footprint o >20% wobec samego GreenCourier.
[#JE-8] Benchmarking suite dla serverless JS: standaryzowany zestaw zadań FaaS
Status: new Priorytet: low Dodano: 2026-05-25
Stworzenie otwartego benchmark suite specyficznego dla serverless JS — analogia do Computer Language Benchmarks Game (CLBG), ale skoncentrowana na typowych FaaS workloadach: API gateway, auth middleware, image processing, SSR, background job. Open-source, CI/CD-ready, z pomiarem energii.
🔬 Hipotezy — zestawienie zbiorcze
| ID | Hipoteza | Testowana w | Spodziewany wynik |
|---|---|---|---|
| H1a | Bun < Node.js energetycznie dla CPU-bound | JE-1 | Potwierdzenie (JavaScriptCore efektywniejszy) |
| H1b | Deno < Node.js energetycznie dla async I/O | JE-1 | Możliwe potwierdzenie (Tokio async) |
| H1c | Brak “zawsze najlepszego” runtimes | JE-1 | Potwierdzenie (zależność od workloadu) |
| H2a | TOPSIS energy:latency:cost wystarczający | JE-2 | Do walidacji |
| H2b | Model decyduje inaczej niż latency-only w >30% | JE-2 | Do walidacji |
| H3a | V8 wymaga 10-15 warm-up iteracji | JE-3 | Do pomiaru |
| H3b | GC spikes >5% wpływ na medianę energii | JE-3 | Prawdopodobne |
| H3c | RAPL vs hardware: R²>0.95 | JE-3 | Potwierdzenie (literatura) |
| H4a | Wasm AoT < Node.js cold start energia | JE-4 | Możliwe potwierdzenie (Lumos) |
| H4b | Edge hardware amplifikuje różnice runtime | JE-4 | Do zbadania |
| H6a | Keep-warm opłacalne energetycznie przy >1/5min | JE-6 | Do obliczenia |
📚 Kluczowe luki badawcze (Research Gaps)
- Główna luka (#JE-1): Brak jakichkolwiek pomiarów energetycznych Node.js/Deno/Bun — Smirnov (2024) mierzy tylko czas
- Metodologiczna luka (#JE-3): Brak standaryzowanego protokołu uwzględniającego JIT warm-up i GC dla JS
- Kontekst luka (#JE-4): Lumos (2025) pomija pomiar energii, De Macedo (2022) pomija serverless i nowe runtimes
- Model decyzyjny (#JE-2): Brak wielokryterialnego modelu energia×latencja×koszt dla JS runtime selection
- Cold start energia (#JE-6): Golec (2024) obszerny przegląd cold start — bez wymiaru energetycznego