fixing the docs; removing the bitbucket mention from the readme

Author: dadhi

Extensions.md

@@ -41,7 +41,7 @@
 
 ## Companions in this repository
 
-Companion packages do not depend on DryIoc package.
+Companion packages different from the Extensions because they do not depend on the DryIoc package.
 
 ### DryIocAttributes
 

README.md

@@ -34,8 +34,7 @@ DryIoc is fast, small, full-featured IoC Container for .NET
 - [Extensions and Companions](Extensions.md)
 - [Documentation][WikiHome]
 - [Contribution guide](CONTRIBUTING.md)
-- Check the old issues on [BitBucket](https://bitbucket.org/dadhi/dryioc)
-- Two original parts of DryIoc are now separate projects: [FastExpressionCompiler](https://github.com/dadhi/FastExpressionCompiler) and [ImTools](https://github.com/dadhi/ImTools)
+- Two original parts of the DryIoc are now the separate projects: [FastExpressionCompiler](https://github.com/dadhi/FastExpressionCompiler) and [ImTools](https://github.com/dadhi/ImTools)
 
 ## Benchmarks
 
@@ -172,8 +171,8 @@ Intel Core i7-8750H CPU 2.20GHz (Coffee Lake), 1 CPU, 12 logical and 6 physical
 * Service lifetime control via *Reuse* and lifetime scoping:
     * Nested disposable scopes with optional names 
     * Optional ambient scope context
-    * Reuse types: `Transient`, `Singleton`, `Scoped` in multiple flavors (including scoping to the specific service ancestor in the object graph)
-    * Option to `useParentReuse` and to `useDecorateeReuse` for decorators
+    * Reuse types: `Transient`, `Singleton`, `Scoped` in multiple flavors including the scoping to the specific service ancestor in the object graph
+    * Option to `useParentReuse` and to `useDecorateeReuse` (for decorators)
     * Option to `preventDisposal` and `weaklyReferenced`
 * Open-generics support including type constraints, variance, complex nesting and recurring definitions.
 * Constructor parameters injection and optional property and field injection.
@@ -183,7 +182,7 @@ Intel Core i7-8750H CPU 2.20GHz (Coffee Lake), 1 CPU, 12 logical and 6 physical
     * Nested with the relative order control
     * Generic and non-generic
     * With the Reuse possibly different from the decorated service
-    * Decorators of wrapped service
+    * Decorators of the Wrappers
 * [Wrappers](https://github.com/dadhi/DryIoc/blob/master/docs/DryIoc.Docs/Wrappers.md):
     * Service collections: `T[]`, `IEnumerable<T>`, `LazyEnumerable<T>`, and  `I(ReadOnly)Collection|List<T>`
     * Single service wrappers: `Lazy<T>`, `Func<T>`, `Meta<TMetadata, T>` or `Tuple<TMetadata, T>`, `KeyValuePair<TKey, T>`

docs/DryIoc.Docs/ResolutionPipeline.md

@@ -9,28 +9,29 @@
 
 ## Overview
 
-What happens when you call `container.Resolve<X>();` for the same service `X` multiple times in a sequence assuming that the `X` is not a singleton*:
+What happens when you call the `container.Resolve<X>()` for the service `X` multiple times in a sequence assuming that the `X` is not a singleton*:
 
-1. The first call will **discover and construct the expression tree** of `X` object graph, **interpret** the expression to get the service, and if succeeded will **cache the expression** in resolution cache.
-2. The second call will find cached expression, will **compile** it to delegate, then it will **replace the cached expression with the delegate** and will invoke the delegate to get the service.
+1. The first call will **discover and construct the expression tree** of `X` object graph, will **interpret** the expression to get the service, and if succeeded will **cache the expression** in the resolution cache, and will return the interpreted service.
+2. The second call will find the cached expression, will **compile** it to the delegate, then it will **replace the cached expression with the delegate** and will invoke the delegate to get the service.
 3. The third call will find the cached delegate and invoke it.
 
-singleton* - those are always interpreted (cannot be changed via rules) and injected in object graph as `ConstantExpression` unless wrapped in Func or Lazy wrappers (which create singleton when consumer demand). 
-This is because they need to be created once and one-time interpretation is faster than compilation+invocation.
+singleton* - those are always interpreted (this cannot be changed via rules) and injected in the object graph as a `ConstantExpression` unless wrapped in `Func` or `Lazy` wrappers (which create the singleton on demand). 
+The reason for that is the singletons are created once and the one-time interpretation is faster than the compilation+invocation.
 
 
 ## Relative Performance
 
+- Delegate invocation is the fastest
 - Expression interpretation is 10x times slower than the delegate invocation
-- Delegate compilation is 100x slower than interpretation.
+- Delegate compilation is 100x slower than the interpretation.
 
 That's mean you need **once** to spend 100x more time than interpretation to get 10x boost, 
 and DryIoc by default is not paying this price.
 
 
 ## Rules.WithUseInterpretation
 
-The compilation (essentially `System.Reflection.Emit`) is not supported by all targets, e.g. Xamarin iOS. In this case, you may specify to always use interpretation via 
+The compilation (essentially `System.Reflection.Emit`) is not supported by all targets, e.g. by the Xamarin iOS. In this case you may specify to always use the interpretation via the rule: 
 
 ```cs
 var c = new Container(rules => rules.WithUseInterpretation());