From 192e443b7cd7ff11f6cd89f81bc45449790bac89 Mon Sep 17 00:00:00 2001
From: Federico Stazi <34340238+FedericoStazi@users.noreply.github.com>
Date: Tue, 22 Sep 2020 15:44:39 +0100
Subject: [PATCH] Update README.md

---
 oss-internship-2020/libuv/README.md | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/oss-internship-2020/libuv/README.md b/oss-internship-2020/libuv/README.md
index 66eeb48..bc49e80 100644
--- a/oss-internship-2020/libuv/README.md
+++ b/oss-internship-2020/libuv/README.md
@@ -60,15 +60,3 @@ Each example and test has an ad-hoc policy implemented on its own file. These po
 ## Callbacks
 
 The `callbacks.h` and `callbacks.cc` files in the `callbacks` folder implement all the callbacks used by examples and tests.
-
-## Performance
-
-A LibUV program looks like this:
-- Setup the loop
-- Run the loop
-- Close the loop
-
-And the second step (running the loop) is the only performance critical part, because this is were actual I/0 and events handling happens. But since this only involves a single call (to `sapi_uv_run`), the overhead from Sandboxed API is constant with respect to the number of handles and requests. 
-In other words, after Sandboxed API has called the `uv_run` method on the sandboxed process, whatever happens there is the same as what would have happened in a regular process running LibUV with no sandbox.
-
-This means that, because of LibUV's nature, Sandboxed API has a totally negligible impact on performance. However, there is and overhead caused by `seccomp-bpf` for each syscall.