[libfuzzer] update Efficient Fuzzer Guide and small fixes to documentation.

testing/libfuzzer/efficient_fuzzer.md

Index: testing/libfuzzer/efficient_fuzzer.md
diff --git a/testing/libfuzzer/efficient_fuzzer.md b/testing/libfuzzer/efficient_fuzzer.md
index cd8cf74b11f6fa72fab0895422c6612583596ed9..9cf28e4e25b2af98bc441b8340a6ed332563e57b 100644
--- a/testing/libfuzzer/efficient_fuzzer.md
+++ b/testing/libfuzzer/efficient_fuzzer.md
@@ -32,6 +32,24 @@ Because libFuzzer performs randomized search, it is critical to have it as fast
 as possible. You should try to get to at least 1,000 exec/s. Profile the fuzzer
 using any standard tool to see where it spends its time.
 
+Avoid allocation of dynamic memory wherever possible. Instrumentation works

[aarya, 2016/04/06 17:26:07]

YOu should name these two lines into a section like "Memory Allocation" or
"Memory Usage".

[aizatsky, 2016/04/06 18:29:16]

Agree. Plus I think it should be moved later in the document. 

[mmoroz, 2016/04/07 13:35:06]

Done.

[mmoroz, 2016/04/07 13:35:06]

Done.

+faster for stack-based and static objects than for heap allocated ones.
+
+Experiment with different values of `-max_len` parameter. This parameter often

[aarya, 2016/04/06 17:26:07]

Lines 38051 should be in a "Maximum Testcase Length" or "Testcase Size" or some
thing like that section.

[mmoroz, 2016/04/07 13:35:06]

Done.

+significantly affects execution speed, but not always.
+
+1) Define which `-max_len` value is reasonable for your target. For example, it
+may be useless to fuzz an image decoder with too small value for `-max_len`.
+2) Increase the value defined on previous step. Check its influence on execution
+speed of fuzzer. If speed doesn't drop significantly for long inputs, it is fine
+to have some bigger value for `-max_len`.
+
+In general, bigger `-max_len` value gives better coverage. Coverage is main
+priority for fuzzing. However, low execution speed may result in waste of
+resources used for fuzzing. If large inputs make fuzzer too slow you have to
+adjust value of `-max_len` and find a trade-off between coverage and execution
+speed.
+
 ### Initialization/Cleanup
 
 Try to keep your fuzzing function as simple as possible. Prefer to use static
@@ -41,7 +59,7 @@ every single run.
 Fuzzers don't have to shutdown gracefully (we either kill them or they crash
 because sanitizer has found a problem). You can skip freeing static resource.
 
-Of course all resources allocated withing `LLVMFuzzerTestOneInput` function
+Of course all resources allocated within `LLVMFuzzerTestOneInput` function
 should be deallocated since this function is called millions of times during
 one fuzzing session.
 
@@ -58,7 +76,7 @@ magic numbers etc. The easiest way to diagnose this problem is to generate a
 [coverage report](#Coverage). To fix the issue you can:
 
 * change the code (e.g. disable crc checks while fuzzing)
-* prepare [corpus seed](#Corpus-Seed).
+* prepare [corpus seed](#Corpus-Seed)
 * prepare [fuzzer dictionary](#Fuzzer-Dictionary)
 
 ## Coverage
@@ -87,8 +105,11 @@ You can pass a corpus directory to a fuzzer that you run manually:
 The directory can initially be empty. The fuzzer would store all the interesting
 items it finds in the directory. You can help the fuzzer by "seeding" the corpus:
 simply copy interesting inputs for your function to the corpus directory before
-running. This works especially well for file-parsing functionality: just
-use some valid files from your test suite.
+running. This works especially well for strictly defined file formats or data
+transmission protocols.
+* For file-parsing functionality just use some valid files from your test suite.
+* For protocol processing targets put raw streams from test suite into separate
+files.
 
 After discovering new and interesting items, [upload corpus to ClusterFuzz].