From 4197a26a3765a4b3b5dd10669e2f4f76742558fa Mon Sep 17 00:00:00 2001 From: Didier Durand Date: Sun, 20 Sep 2020 10:33:22 +0200 Subject: Fix a couple of typos on performance.md 2 typos spotted in current version and fixed. Best Didier --- g3doc/architecture_guide/performance.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'g3doc/architecture_guide') diff --git a/g3doc/architecture_guide/performance.md b/g3doc/architecture_guide/performance.md index 39dbb0045..ae85f3ddd 100644 --- a/g3doc/architecture_guide/performance.md +++ b/g3doc/architecture_guide/performance.md @@ -30,7 +30,7 @@ is distinct from **structural costs**. Improvements here are ongoing and driven by the workloads that matter to gVisor users and contributors. This page provides a guide for understanding baseline performance, and calls out -distint **structural costs** and **implementation costs**, highlighting where +distinct **structural costs** and **implementation costs**, highlighting where improvements are possible and not possible. While we include a variety of workloads here, it’s worth emphasizing that gVisor @@ -211,7 +211,7 @@ url="/performance/applications.csv" title="perf.py http.(node|ruby) The above figure shows the result of simple `node` and `ruby` web services that render a template upon receiving a request. Because these synthetic benchmarks -do minimal work per request, must like the `redis` case, they suffer from high +do minimal work per request, most like the `redis` case, they suffer from high overheads. In practice, the more work an application does the smaller the impact of **structural costs** become. -- cgit v1.2.3