Pith. sign in

REVIEW 4 major objections 5 minor 42 references

Truffle: Efficient Data Passing for Data-Intensive Serverless Workflows in the Edge-Cloud Continuum

T0 review · 4 major / 5 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper claims that the idle time of a serverless function's cold start can be repurposed to fetch and pass input data, reducing the I/O latency impact on function execution time by up to 77% and overall execution time by up to 46%.

desk verdict A simple, credible idea—overlap cold start with data transfer—with an honest model and open code; the experiments support the direction but not the headline magnitude. read the letter →

arxiv 2411.16451 v1 pith:P3DN6TKP submitted 2024-11-25 cs.DC

Cynthia Marcelino , Stefan Nastic This is my paper · ORCID
classification cs.DC
keywords serverlesscomputingcoldstartdatapassingedge-cloudcontinuumdata-intensiveworkflowsfunction-as-a-serviceprefetchinginter-functioncommunication
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Serverless workflows pass data between functions through external storage because functions are not directly addressable, and the paper's own experiments show that cold start plus data transfer dominate the function execution lifecycle. Truffle is a model and runtime architecture that separates computation from I/O, so that as soon as a function is scheduled, its input data begins being fetched and passed to a local buffer while the function container is still starting up. The paper's central claim is that this overlap replaces the sequential sum of cold start and data transfer with their maximum, and the reported experiments show up to 77% reduction in the I/O latency impact and up to 46% reduction in total workflow execution time relative to direct, key-value store, and object storage baselines. If this holds, the normally idle startup window becomes useful work, with the largest benefits for functions that combine long cold starts with large inputs.

What carries the argument

The load-bearing identity is $\tau(\lambda_i) = \alpha_i + \max(\beta_i, \delta_i) + \gamma_i$, which rewrites the function lifecycle as a parallel instead of sequential process: the data transfer $\delta_i$ overlaps the cold start $\beta_i = \upsilon_i + \eta_i$ (infrastructure setup plus runtime startup), so the two contribute only the longer of the two. Two runtime mechanisms implement it: Smart Data Prefetch (SDP), which identifies the input storage type, starts fetching at request arrival, and stages data in a buffer; and Cold Start Pass (CSP), which watches the orchestrator for the target function's assigned host and pushes the data to that node's buffer during the cold-start window. The Buffer is the rendezvous point: when the function finally executes, its input is already local.

What would settle it

Run the same workflow on a node where network or memory is deliberately saturated and compare the measured end-to-end time with $\alpha + \max(\beta, \delta) + \gamma$; if the total grows by more than $\min(\beta, \delta)$ as both the cold start and the transfer are lengthened together, the overlap is not free and the model overstates the gain.

Watch

Extended reading notes

Core claim

The discovery is that a serverless function's cold start is not dead time if I/O is scheduled independently of computation. Because the target host for a function is known as soon as scheduling finishes, Truffle's Smart Data Prefetch begins retrieving input data from the identified storage source at request arrival, and its Cold Start Pass transfers inter-function data to the target node's buffer during the same window in which the function is being provisioned. The paper expresses the result as end-to-end function time $\tau = \alpha + \max(\beta, \delta) + \gamma$, where $\alpha$ is scheduling, $\beta$ is the cold start (made up of infrastructure setup plus startup), $\delta$ is data transfer, and $\gamma$ is the function's own execution; the saving over a sequential lifecycle is $\Delta = \min(\beta, \delta)$. Evaluations on chained and video-analytics workflows show the I/O latency impact falling by up to 77% and overall function execution time improving by up to 46% against the baselines, and applications with cold starts near 10 s gaining nearly 30% more than applications with cold starts near 2 s.

Load-bearing premise

The model assumes that data transfer and cold start run at the same time on the same node without slowing each other down; the paper never measures that contention, so the claimed overlap benefit would shrink on resource-saturated nodes if prefetching competes with startup for bandwidth, CPU, or memory.

Editorial extensions

If this is right

  • Workflows with long cold starts gain most: the paper reports up to 30% extra latency reduction for cold starts near 10 s compared with near 2 s.
  • Developers can stop writing code that fetches input inside the function handler, because SDP abstracts storage type and stages data before execution begins.
  • The effective end-to-end time follows the maximum of cold start and data transfer, not their sum, so the shorter of the two stops being a visible latency component.
  • Because the buffer is local to the worker, downstream functions read input from near memory instead of from remote object storage or key-value stores.
  • Truffle is compatible with cold-start mitigation techniques such as snapshot caching and sandbox sharing, so those can be stacked on top rather than treated as alternatives.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper, the same overlap idea could hide other startup work—dependency decompression, serialization, argument validation—inside the cold start; the authors list this as future work but do not evaluate it.
  • Beyond the paper, real workloads with mixed warm and cold invocations would show smaller average gains than these cold-start-only measurements, because Truffle acts as a transparent proxy when the target function is already running.
  • Beyond the paper, a contention-aware model in which the cold start lengthens by some function of transfer size would let schedulers decide when prefetching is worth it on saturated edge nodes; the current max formula assumes no such cost.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper presents Truffle, a model and architecture for data passing in serverless workflows that overlaps input data transfer with the function cold start. The model in Section III-A expresses end-to-end execution time as τ = α + max(β, δ) + γ, so that overlapping cold start β and data transfer δ yields an improvement Δ = min(β, δ). The implementation includes Smart Data Prefetch (SDP), which fetches input data into a local buffer during startup, and Cold Start Pass (CSP), which transfers data between functions after scheduling and before execution. The evaluation compares Truffle with Direct, KVS, and S3 baselines on two workflows, reporting up to 77% reduction in IO latency impact and up to 46% reduction in overall latency, with a separate experiment showing larger gains for longer cold starts.

Significance. The core idea of exploiting the idle cold-start window for data transfer is timely and practically relevant for data-intensive serverless workloads in the edge-cloud continuum. The model is an analytic identity with no fitted parameters, and the paper provides an open-source implementation, which are strengths. The related work is well covered and the proposed mechanisms are clearly described. However, the experimental evaluation has important gaps: the headline improvements are best-case numbers with no variance reporting, the cold-start-delay experiments use artificial idle delays rather than realistic provisioning work, and the model's zero-interference assumption is not tested under resource contention. These issues limit the strength of the empirical claims and the generalizability of the results.

major comments (4)
  1. [Section VI-C, Figs. 9-10] The improvements reported in Figs. 9 and 10 range from 5% to 46% depending on the storage type and workflow, yet no standard deviations, confidence intervals, or number of repetitions are provided. The abstract's 'up to 46%' is the single best case (Direct data passing at 128MB in Chained Functions) and most other comparisons show much smaller gains (e.g., 5% for KVS in Chained Functions, 6% for Direct in Video Analytics). Please provide variance information and clearly state which experimental condition the headline numbers refer to, so readers can assess the significance and typical magnitude of the improvement.
  2. [Section III-A, Eq. (3)] The model assumes that cold start (β) and data transfer (δ) can be overlapped with zero mutual interference. In Truffle's design, prefetching consumes the same node's network bandwidth, disk I/O, and CPU as the provisioning process (e.g., image pulls, runtime initialization), so β may increase when data is fetched concurrently. The evaluation does not measure β and δ in isolation under load, nor does it include resource-constrained scenarios typical of edge nodes. Please either add experiments with constrained bandwidth/CPU or explicitly discuss this limitation and bound the potential degradation of the reported improvements.
  3. [Section VI-D, Fig. 11] The cold-start-delay experiment artificially inflates the cold start by adding idle sleep delays, which does not reproduce real provisioning activity such as image pulling or runtime initialization. The flat region in the Truffle curve in Fig. 11 is thus a direct consequence of the model's assumption that the added delay is idle wait, not a demonstration under realistic workloads. Please clarify what the added delay represents and, if possible, validate the overlap behavior with an actual resource-consuming cold-start task.
  4. [Section VI-A] The latency metric is not precisely defined. The text says it is 'the time when the data is sent until the target functions receive the data' but also states that the measurement includes 'the entire target function startup including scheduling, cold start, and data transfer latency.' It is unclear whether the function execution time γ in the model is included in this metric and how 'receive' is detected. Please provide an operational definition of the metric and explain how it maps to the model's τ.
minor comments (5)
  1. [Section III-A, Eq. (3)] The notation is inconsistent: Eq. (3) writes τ(λ_i) on the left-hand side, but the summation index i is also used for the individual function, and the upper limit n is missing. Please clarify whether τ is the total workflow time or per-function time.
  2. [Section VI-C, Fig. 8] The values supporting the 77% IO-latency-impact reduction are not stated in the text; Fig. 8 shows bars but the reader cannot verify the claimed number. Please provide the exact percentages or a table for each comparison.
  3. [Section VI-D] The text states 'Truffle shows a latency decrease of up to 30%' for longer cold starts and 'While applications with short cold start might profit 3%,' but these numbers are not tied to a specific figure or table with the exact experimental conditions. Please label them clearly.
  4. [Algorithm 2, Section IV-B] The pseudocode in Algorithm 2 does not include the 'stop listening' step that is described in the text after the host address is found; please align the algorithm with the description.
  5. [Section VIII] The conclusion states that functions with longer cold starts 'profit nearly 30% more' than those with shorter ones, but Section VI-D says 'up to 30%' and '3%' for short cold starts. Please ensure these numbers are consistent and clearly reported.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the overlap model is an arithmetic identity, the improvements are measured against external baselines, and the self-citations are background only.

full rationale

The paper's formal model in Section III-A defines end-to-end time as τ(λi) = αi + max((υi+ηi), δi) + γi and improvement as Δi = (βi+δi) − max(βi,δi). This is a definitional identity describing what happens when a sequential delay is replaced by parallel execution; it is not a fitted parameter, and the paper does not use Eq. (4) as the source of its empirical numbers. The headline results (up to 77% reduction of IO latency impact and up to 46% improvement in function execution time) are obtained from direct latency measurements comparing Truffle against Direct, KVS, and S3 baselines in Section VI-C (Figs. 7-10), and the cold-start-delay experiments in Section VI-D also report measured latencies rather than evaluating the model formula. The only self-citations, CWASI [22] and Goldfish [23], appear in the related-work discussion as prior sandbox-sharing and stateful-serverless background; neither is load-bearing for Truffle's design, and no uniqueness theorem or ansatz is imported from the authors' prior work. The assumption in Eq. (3) that cold start and data transfer can overlap without mutual interference is a legitimate correctness concern about resource contention under load, but it is not circularity: the claimed improvements are externally measured and would fail if the assumption were false, which is precisely what makes the claim empirically falsifiable. Accordingly, no circular step is present.

Assumptions & free parameters 0 free parameters · 3 assumptions · 4 invented entities

The paper introduces no fitted numerical parameters. It relies on domain assumptions about the serverless lifecycle and orchestrator observability, plus the unstated assumption that prefetching is free of resource contention. The invented entities are software components; the open-source implementation gives them an independent falsifiable handle.

assumptions (3)
  • domain assumption The serverless function lifecycle phases (scheduling, cold start, I/O, execution) are executed sequentially in state-of-the-art platforms.
    Stated in Section II-A and Fig. 2; this is the bottleneck Truffle targets.
  • domain assumption The function's target host is known immediately after the scheduling phase and can be observed via orchestration APIs.
    Section IV-B, Watcher component; Truffle relies on Kubernetes events to learn the host address.
  • ad hoc to paper Data transfer during cold start does not delay the cold start itself (no resource contention).
    Section III-A Eq. (3) assumes total time is max(β,δ), implying overlap is free; the paper does not measure interference.
invented entities (4)
  • Truffle Buffer independent evidence
    purpose: Local or remote storage that holds prefetched input data until the function is provisioned.
    Implemented in Go in the open-source repository; the experiments exercise it.
  • Watcher component independent evidence
    purpose: Listens to orchestration (Kubernetes) events to determine the target host for a function after scheduling.
    Part of the open-source implementation; its behavior is triggered in the cold start pass experiments.
  • Smart Data Prefetch (SDP) independent evidence
    purpose: Abstracts retrieval of function input data from different storage types during cold start.
    Evaluated in Figures 9-11.
  • Cold Start Pass (CSP) independent evidence
    purpose: Transfers inter-function data to the target host during the cold start window.
    Central mechanism; relies on Watcher and Buffer.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Truffle: Efficient Data Passing for Data-Intensive Serverless Workflows in the Edge-Cloud Continuum." pith.science (2026). https://pith.science/paper/P3DN6TKP

@misc{pith2026241116451,
  author       = {Pith},
  title        = {Pith review of: Truffle: Efficient Data Passing for Data-Intensive Serverless Workflows in the Edge-Cloud Continuum},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/P3DN6TKP}},
  note         = {Machine review of arXiv:2411.16451}
}
read the original abstract

Serverless computing promises a scalable, reliable, and cost-effective solution for running data-intensive applications and workflows in the heterogeneous and limited-resource environment of the Edge-Cloud Continuum. However, building and running data-intensive serverless workflows also brings new challenges that can significantly degrade the application performance. Cold start remains one of the main challenges that impact the total function execution time. Further, since the serverless functions are not directly addressable, Serverless workflows need to rely on external (storage) services to pass the input data to the downstream functions. Empirical evidence from our experiments shows that the cold start and the function data passing take up the most time in the function execution lifecycle. In this paper, we introduce Truffle - a novel model and architecture that enables efficient inter-function data passing in the Edge-Cloud Continuum by introducing mechanisms that separate computation and I/O, allowing serverless functions to leverage the cold starts to their advantage. Truffle introduces Smart Data Prefetch (SDP) mechanism that abstracts the retrieval of input data for the serverless functions by triggering the data retrieval from the external storage during the function's startup. Truffle's Cold Start Pass (CSP) mechanism optimizes inter-function data passing and data exchange within serverless workflows in the Edge-Cloud Continuum by hooking into the functions' scheduling lifecycle to trigger early data passing during the function's cold start. Experimental results show that by leveraging the data prefetching and cold-start data passing, Truffle reduces the IO latency impact on the total function execution time by up to 77%, improving the function execution time by up to 46% compared to the state-of-the-art data passing approaches.

Figures

Figures reproduced from arXiv: 2411.16451 by the authors.

Figure 1
Figure 1. Knative Serverless function lifecycle steps duration with [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Serverless Function Lifecycle with 1MB Input Data [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Simplified Serverless Workflow for Fire Detection for [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (8 more)
Figure 4
Figure 4. Figure 4: shows Truffle’s interaction with the function and the serverless and orchestration platform. Truffle has a modular architecture that allows each component to be extended and eventually replaced. Truffle components enable two main mechanisms: Smart Data Prefetch and Col…
Figure 5
Figure 5. Figure 5: Truffle Smart Data Prefetch Algorithm 1 Truffle Smart Data Prefetch Require: R: incoming request Require: BN : buffer name Require: ST : storage type Require: CR: content reference 1: B ← buffer 2: SC ← storage 3: for all BT ∈ BC do 4: if BT ̸= ∅ ∧ BT = BN then 5: B ← …
Figure 6
Figure 6. Figure 6: Truffle Cold Start Pass Algorithm 2 Truffle Cold Start Pass Request Require: TF : target function Require: TC : target content 1: HA ← ∅ 2: W ← resource watcher 3: for all F(F ∈ FE, ∀FE ∈ W) do 4: if FH ̸= ∅ ∧ TF = FN then 5: HA ← FH 6: end if 7: end for 8: call target…
Figure 7
Figure 7. Figure 7: Total Workflow Execution Latency for 128MB, includ [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 8
Figure 8. Figure 8: IO latency impact on the total workflow execution for [PITH_FULL_IMAGE:figures/full_fig_p007_8.png]
Figure 9
Figure 9. Figure 9: Chained Functions Latency 0 10 20 30 40 4.5 5 5.5 Function input size in MB Latency (sec) Truffle Direct (a) Direct Data Passing 0 10 20 30 40 4 6 8 10 Function input size in MB Truffle+KVS KVS (b) KVS Data Passing 0 10 20 30 40 4 6 Function input size in MB Truffle+S3…
Figure 10
Figure 10. Figure 10: Video Analytics Latency 0 2 4 6 8 10 5 10 15 Added Delay (sec) Latency (sec) Truffle+S3 S3 0 2 4 6 8 10 5 10 15 Added Delay (sec) Latency (sec) Truffle+KVS KVS [PITH_FULL_IMAGE:figures/full_fig_p008_10.png]
Figure 11
Figure 11. Figure 11: Additional Cold Start Delay with 100MB input [PITH_FULL_IMAGE:figures/full_fig_p008_11.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

42 extracted references · 38 canonical work pages

  1. [1]

    Alexandru Agache et al. 2020. Firecracker: lightweight virtualization for serverless applications. In 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI 20) . USENIX Association, Santa Clara, CA, (Feb. 2020), 419–434

    work page 2020

  2. [2]

    Istemi Ekin Akkus et al. 2018. SAND: towards High-Performance serverless computing. In 2018 USENIX Annual Technical Conference (USENIX ATC 18) . USENIX Association, Boston, MA, (July 2018), 923–935

    work page 2018

  3. [3]

    Amazon s3

    2023. Amazon s3. https://aws.amazon.com/de/s3/

    work page 2023

  4. [4]

    James Cadden et al. 2020. Seuss: skip redundant paths to make serverless fast. In Proceedings of the Fifteenth European Conference on Computer Systems (EuroSys ’20). Association for Computing Machinery, Heraklion, Greece. DOI: 10.1145/3342195.3392698

    work page arXiv 2020

  5. [5]

    J´anos Czentye and Bal ´azs Sonkoly. 2024. Serverless application composition leveraging function fusion: theory and algorithms. Future Generation Computer Systems , 403–418

    work page 2024

  6. [6]

    Nilanjan Daw et al. 2020. Xanadu: mitigating cascading cold starts in serverless function chain deployments. In Proceedings of the 21st International Middleware Conference (Middleware ’20). Association for Computing Machinery, Delft, Netherlands, 356–370

    work page 2020

  7. [7]

    Simon Eismann et al. 2021. Serverless applications: why, when, and how? IEEE Software, 1, 32–39. DOI: 10.1109/MS.2020.3023302

    arXiv 2021

  8. [8]

    Simon Eismann et al. 2022. The state of serverless applications: collec- tion, characterization, and community consensus. IEEE Transactions on Software Engineering , 10, 4152–4166. DOI: 10.1109/TSE.2021.311 3940

    work page doi:10.1109/tse.2021.311 2022

Show all 42 references
  1. [9]

    Juan Jos ´e L ´opez Escobar et al. 2024. Unleashing the power of decentralized serverless iot dataflow architecture for the cloud-to-edge continuum: a performance comparison. Annals of Telecommunications, 1–14

    2024

  2. [10]

    Alexander Fuerst and Prateek Sharma. 2021. Faascache: keeping serverless computing alive with greedy-dual caching. In Proceedings of the 26th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS ’21). Association for Com...

    2021

  3. [11]

    Alim Ul Gias and Giuliano Casale. 2020. Cocoa: cold start aware capacity planning for function-as-a-service platforms. In 2020 28th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS) , 1–8

    2020

  4. [12]

    Hellerstein et al

    Joseph M. Hellerstein et al. 2018. Serverless computing: one step forward, two steps back. (2018). arXiv: 1812.03651 [cs.DC]

    2018 arXiv

  5. [13]

    Zhuo Huang et al. 2023. Duo: improving data sharing of stateful serverless applications by efficiently caching multi-read data. In 2023 IEEE International Parallel and Distributed Processing Symposium (IPDPS), 875–885

    2023

  6. [14]

    Zhipeng Jia and Emmett Witchel. 2021. Nightcore: efficient and scalable serverless computing for latency-sensitive, interactive microservices. In Proceedings of the 26th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPL...

    2021

  7. [15]

    Eric Jonas et al. 2019. Cloud programming simplified: a berkeley view on serverless computing. (2019). arXiv: 1902.03383 [cs.OS]

    2019 arXiv

  8. [16]

    Ana Klimovic et al. 2018. Pocket: elastic ephemeral storage for serverless analytics. In 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18) . USENIX Association, Carlsbad, CA, (Oct. 2018), 427–444

    2018

  9. [17]

    Swaroop Kotni et al. 2021. Faastlane: accelerating Function-as-a-Service workflows. In 2021 USENIX Annual Technical Conference (USENIX ATC 21). USENIX Association, (July 2021), 805–820

    2021

  10. [18]

    Tom Kuchler et al. 2023. Function as a function. In Proceedings of the 2023 ACM Symposium on Cloud Computing (SoCC ’23). Association for Computing Machinery, Santa Cruz, CA, USA, 81–92

    2023

  11. [19]

    Xuanzhe Liu et al. 2023. Faaslight: general application-level cold-start latency optimization for function-as-a-service in serverless computing. ACM Trans. Softw. Eng. Methodol. , 5

    2023

  12. [20]

    Talaat and Hanaa Zaineldin

    Fatma M. Talaat and Hanaa Zaineldin. 2023. An improved fire detection approach based on yolo-v8 for smart cities. Neural Computing and Applications, (July 2023)

    2023

  13. [21]

    Ashraf Mahgoub et al. 2021. SONIC: application-aware data passing for chained serverless applications. In 2021 USENIX Annual Technical Conference (USENIX ATC 21) . USENIX Association, (July 2021), 285–301

    2021

  14. [22]

    Cynthia Marcelino and Stefan Nastic. 2023. Cwasi: a webassembly runtime shim for inter-function communication in the serverless edge- cloud continuum. In The Eighth ACM/IEEE Symposium on Edge Computing (SEC 2023)

    2023

  15. [23]

    Cynthia Marcelino et al. 2024. Goldfish: serverless actors with short- term memory state for the edge-cloud continuum. In Proceedings of the 14th International Conference on the Internet of Things (IoT ’24). ACM, Oulu, Finland

    2024

  16. [24]

    Djob Mvondo et al. 2021. Ofc: an opportunistic caching system for faas platforms. In Proceedings of the Sixteenth European Conference on Computer Systems (EuroSys ’21). Association for Computing Machinery, Online Event, United Kingdom, 228–244

    2021

  17. [25]

    Stefan Nastic et al. 2022. A serverless computing fabric for edge & cloud. In 2022 IEEE 4th International Conference on Cognitive Machine Intelligence (CogMI) , 1–12

    2022

  18. [26]

    Edward Oakes et al. 2018. SOCK: rapid task provisioning with Serverless-Optimized containers. In 2018 USENIX Annual Technical Conference (USENIX ATC 18) . USENIX Association, Boston, MA, (July 2018), 57–70

    2018

  19. [27]

    Li Pan et al. 2022. Retention-aware container caching for serverless edge computing. In IEEE INFOCOM 2022 - IEEE Conference on Computer Communications, 1069–1078

    2022

  20. [28]

    Thomas Pusztai et al. 2024. Hyperdrive: scheduling serverless functions in the edge-cloud-space 3d continuum. In Proceedings of the Ninth ACM/IEEE Symposium on Edge Computing (SEC ’24). Association for Computing Machinery, Rome, Italy

    2024

  21. [29]

    Philipp Raith et al. 2023. Serverless edge computing—where we are and what lies ahead. IEEE Internet Computing , 3, 50–64

    2023

  22. [30]

    Rohan Basu Roy et al. 2022. Icebreaker: warming serverless functions better with heterogeneity. In Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS ’22). Association for Computing Machinery, L...

    2022

  23. [31]

    Johann Schleier-Smith et al. 2021. What serverless computing is and should become: the next phase of cloud computing. Commun. ACM, 5, 76–84

    2021

  24. [32]

    Simon Shillaker and Peter Pietzuch. 2020. Faasm: lightweight isolation for efficient stateful serverless computing. In 2020 USENIX Annual Technical Conference (USENIX ATC 20) . USENIX Association, (July 2020), 419–433

    2020

  25. [33]

    Sicari et al

    C. Sicari et al. 2023. Tema: event driven serverless workflows platform for natural disaster management. In 2023 IEEE Symposium on Computers and Communications (ISCC) . IEEE Computer Society, Los Alamitos, CA, USA, 1–6

    2023

  26. [34]

    Paulo Silva et al. 2020. Prebaking functions to warm the serverless cold start. In Proceedings of the 21st International Middleware Conference (Middleware ’20). Association for Computing Machinery, Delft, Netherlands, 1–13

    2020

  27. [35]

    Arjun Singhvi et al. 2021. Atoll: a scalable low-latency serverless platform. In Proceedings of the ACM Symposium on Cloud Computing (SoCC ’21). Association for Computing Machinery, Seattle, W A, USA, 138–152

    2021

  28. [36]

    Vikram Sreekanti et al. 2020. Cloudburst: stateful functions-as-a-service. Proc. VLDB Endow., 2438–2452

    2020

  29. [37]

    Yang Tang and Junfeng Yang. 2020. Lambdata: optimizing serverless computing by making data intents explicit. 2020 IEEE 13th Interna- tional Conference on Cloud Computing (CLOUD) , 294–303

    2020

  30. [38]

    Dmitrii Ustiugov et al. 2021. Benchmarking, analysis, and optimization of serverless function snapshots. In Proceedings of the 26th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS’21) . ACM

    2021

  31. [39]

    Dmitrii Ustiugov et al. 2023. Expedited data transfers for serverless clouds. (2023). arXiv: 2309.14821 [cs.DC]

    2023 arXiv

  32. [40]

    Parichehr Vahidinia et al. 2020. Cold start in serverless computing: cur- rent trends and mitigation strategies. In 2020 International Conference on Omni-layer Intelligent Systems (COINS) , 1–7

    2020

  33. [41]

    Vswarm - serverless benchmarking suite

    2023. Vswarm - serverless benchmarking suite. https://github.com/vhiv e-serverless/vSwarm

    2023

  34. [42]

    Ao Wang et al. 2020. InfiniCache: exploiting ephemeral serverless functions to build a Cost-Effective memory cache. In 18th USENIX Conference on File and Storage Technologies (FAST 20) . USENIX Association, Santa Clara, CA, (Feb. 2020), 267–281. 10

    2020

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.