[pypy-commit] extradoc extradoc: some tweaks. looks good, but some more work needed

[cfbolz]

Author: Carl Friedrich Bolz <cfbolz at gmx.de>
Branch: extradoc
Changeset: r5453:5ef5d23c25e3
Date: 2014-11-05 10:07 +0100
http://bitbucket.org/pypy/extradoc/changeset/5ef5d23c25e3/

Log:	some tweaks. looks good, but some more work needed

diff --git a/blog/draft/io-improvements.rst b/blog/draft/io-improvements.rst
--- a/blog/draft/io-improvements.rst
+++ b/blog/draft/io-improvements.rst
@@ -1,20 +1,20 @@
 
 Hello everyone!
 
-We're about to wrap up the Warsaw sprint, so I would like to describe some
+We've wrapped up the Warsaw sprint, so I would like to describe some
 branches which have been recently merged and which improved the I/O and the
 GC: `gc_no_cleanup_nursery`_ and `gc-incminimark-pinning`_.
 
 The first branch was started by Wenzhu Man for her Google Summer of Code
-and finished by Maciej Fijalkowski and Armin Rigo.
+and finished by Maciej Fijałkowski and Armin Rigo.
 The PyPy GC works by allocating new objects in the young object
 area (the nursery), simply by incrementing a pointer. After each minor
 collection, the nursery has to be cleaned up. For simplicity, the GC used 
 to do it by zeroing the whole nursery.
 
-This approach has bad effects on cache, since you zero a large
-memory at once and does unnecessary work for things that don't require zeroing
-like large strings. We somehow mitigated the first problem with incremental
+This approach has bad effects on the cache, since you zero a large piece of
+memory at once and do unnecessary work for things that don't require zeroing
+like large strings. We mitigated the first problem somewhat with incremental
 nursery zeroing, but this branch removes the zeroing completely, thus
 improving the string handling and recursive code (since jitframes don't
 requires zeroed memory either). I measured the effect on two examples: 
@@ -27,7 +27,7 @@
 XXXX
 
 The second branch was done by Gregor Wegberg for his master thesis and finished
-by Maciej Fijalkowski and Armin Rigo. Because of the way it works, the PyPy GC from
+by Maciej Fijałkowski and Armin Rigo. Because of the way it works, the PyPy GC from
 time to time moves the objects in memory, meaning that their address can change.
 Therefore, if you want to pass pointers to some external C function (for
 example, write(2) or read(2)), you need to ensure that the objects they are
@@ -37,7 +37,7 @@
 The branch introduce the concept of "pinning", which allows us to inform the
 GC that it is not allowed to move a certain object for a short period of time.
 This introduces a bit of extra complexity
-in the garbage collector, but improves the the I/O performance quite drastically,
+in the garbage collector, but improves the I/O performance quite drastically,
 because we no longer need the extra copy to and from the non-movable buffers.
 
 In `this benchmark`_, which does I/O in a loop,
@@ -51,6 +51,8 @@
 non-zero-nursery and ``3d8fe96dc4d9`` for non-zero-nursery and pinning.
 The benchmarks were run once, since the standard deviation was small.
 
+XXX explain why files are still bad and what we plan to do about it
+
 XXXX
 
 XXX summary