From 752a9bc51da079438fcaed74c800a91049970c44 Mon Sep 17 00:00:00 2001 From: gorhill Date: Tue, 9 Sep 2014 09:42:12 -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 2b3e927..3d1717e 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 permanently higher memory baseline for µBlock, as can be seen in the browser's _Task Manager_. +Memory-churning operations lead to a 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.