From ee04a1364d7fa8914a0b653ab80c5399f4d7c693 Mon Sep 17 00:00:00 2001 From: gorhill Date: Tue, 9 Sep 2014 09:41:47 -0700 Subject: [PATCH] Updated Notes on memory benchmarks, selfies (markdown) --- ...hmarks,-selfies.md => Notes on memory benchmarks, selfies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename Notes-on-memory-benchmarks,-selfies.md => Notes on memory benchmarks, selfies.md (95%) diff --git a/Notes-on-memory-benchmarks,-selfies.md b/Notes on memory benchmarks, selfies.md similarity index 95% rename from Notes-on-memory-benchmarks,-selfies.md rename to Notes on memory benchmarks, selfies.md index 63be59e..2b3e927 100644 --- a/Notes-on-memory-benchmarks,-selfies.md +++ b/Notes on memory benchmarks, selfies.md @@ -6,7 +6,7 @@ When I run my benchmarks, the methodology used is to reproduce what I believe is However there are specific operations which will cause µBlock to churn through lot of short-term memory (let's call this "memory-churning"), and although all that short-term memory is freed by µBlock once the specific operation is completed, not all that freed memory will be garbage-collected by the browser for whatever reasons. Memory fragmentation is possibly a factor. -Memory-churning operations lead to an higher permanent memory baseline for µBlock, as can be seen in the browser's _Task Manager_. +Memory-churning operations lead to an permanently higher memory baseline for µBlock, as can be seen in the browser's _Task Manager_. So in essence you won't obtain the same memory figures which I used in my published benchmarks if you caused µBlock to go through memory-churning before looking at the memory figures.