branch: elpa/flx
commit c41f9f50870b19505c2bf74a82f0ecf1546db921
Author: Le Wang <le.w...@agworld.com.au>
Commit: Le Wang <le.w...@agworld.com.au>
reorder README sections
---
README.md | 118 +++++++++++++++++++++++++++++++-------------------------------
1 file changed, 59 insertions(+), 59 deletions(-)
diff --git a/README.md b/README.md
index a67330673f..95bce2f951 100644
--- a/README.md
+++ b/README.md
@@ -9,65 +9,6 @@ expect to encounter bugs.
[Screencast showing rationale and ido workflow][]
-## Memory Usage
-
-The `flx` algorithm willingly sacrifices memory usage for speed.
-
-For 10k file names, about 10 MB of memory will be used to speed up future
-matching. This memory is never released to keep the match speed fast.
-
-So far with modern computers, this feels like a reasonable design decision.
-
-It may change in future.
-
-## GC Optimization
-
-Emacs's garbage collector is fairly primitive stop the world type. GC time can
-contribute significantly to the run-time of computation that allocates and
-frees a lot of memory.
-
-Consider the following example:
-
-```lisp
-(defun uuid ()
- (format "%08x-%08x-%08x-%08x"
- (random (expt 16 4))
- (random (expt 16 4))
- (random (expt 16 4))
- (random (expt 16 4))))
-
-(benchmark-run 1
- (let ((cache (flx-make-filename-cache)))
- (dolist (i (number-sequence 0 10000))
- (flx-process-cache (uuid) cache))))
- ;;; ⇒ (0.899678 9 0.33650300000000044)
-```
-
-This means that roughly 30% of time is spent just doing garbage-collection.
-
-`flx` can benefit significantly from garbage collection tuning.
-
-By default Emacs will initiate GC every 0.76 MB allocated (`gc-cons-threshold`
-== 800000). If we increase this to 20 MB (`gc-cons-threshold` == 20000000)
-we get:
-
-````lisp
-(benchmark-run 1
- (setq gc-cons-threshold 20000000)
- (let ((cache (flx-make-filename-cache)))
- (dolist (i (number-sequence 0 10000))
- (flx-process-cache (uuid) cache))))
- ;;; ⇒ (0.62035 1 0.05461100000000041)
-```
-
-So if you have a modern machine, I encourage you to add the following:
-
-```lisp
-(setq gc-cons-threshold 20000000)
-```
-
-to your init file.
-
## Installation
### Manual
@@ -134,6 +75,65 @@ still working through how to integrate it into helm.
The Helm demo shows the score of the top 20 matches.
+## Memory Usage
+
+The `flx` algorithm willingly sacrifices memory usage for speed.
+
+For 10k file names, about 10 MB of memory will be used to speed up future
+matching. This memory is never released to keep the match speed fast.
+
+So far with modern computers, this feels like a reasonable design decision.
+
+It may change in future.
+
+## GC Optimization
+
+Emacs's garbage collector is fairly primitive stop the world type. GC time can
+contribute significantly to the run-time of computation that allocates and
+frees a lot of memory.
+
+Consider the following example:
+
+```lisp
+(defun uuid ()
+ (format "%08x-%08x-%08x-%08x"
+ (random (expt 16 4))
+ (random (expt 16 4))
+ (random (expt 16 4))
+ (random (expt 16 4))))
+
+(benchmark-run 1
+ (let ((cache (flx-make-filename-cache)))
+ (dolist (i (number-sequence 0 10000))
+ (flx-process-cache (uuid) cache))))
+ ;;; ⇒ (0.899678 9 0.33650300000000044)
+```
+
+This means that roughly 30% of time is spent just doing garbage-collection.
+
+`flx` can benefit significantly from garbage collection tuning.
+
+By default Emacs will initiate GC every 0.76 MB allocated (`gc-cons-threshold`
+== 800000). If we increase this to 20 MB (`gc-cons-threshold` == 20000000)
+we get:
+
+````lisp
+(benchmark-run 1
+ (setq gc-cons-threshold 20000000)
+ (let ((cache (flx-make-filename-cache)))
+ (dolist (i (number-sequence 0 10000))
+ (flx-process-cache (uuid) cache))))
+ ;;; ⇒ (0.62035 1 0.05461100000000041)
+```
+
+So if you have a modern machine, I encourage you to add the following:
+
+```lisp
+(setq gc-cons-threshold 20000000)
+```
+
+to your init file.
+
[Screencast showing rationale and ido workflow]:
http://www.youtube.com/watch?v=_swuJ1RuMgk
[Helm]: https://github.com/emacs-helm/helm
