--- CBOR-XS/XS.pm	2013/10/29 20:59:16	1.14
+++ CBOR-XS/XS.pm	2013/11/17 05:26:14	1.18
@@ -48,10 +48,13 @@
 often compresses better than CBOR though, so if you plan to compress the
 data later you might want to compare both formats first).
 
-To give you a general idea, with texts in the megabyte range, C<CBOR::XS>
-usually encodes roughly twice as fast as L<Storable> or L<JSON::XS> and
-decodes about 15%-30% faster than those. The shorter the data, the worse
-L<Storable> performs in comparison.
+To give you a general idea about speed, with texts in the megabyte range,
+C<CBOR::XS> usually encodes roughly twice as fast as L<Storable> or
+L<JSON::XS> and decodes about 15%-30% faster than those. The shorter the
+data, the worse L<Storable> performs in comparison.
+
+As for compactness, C<CBOR::XS> encoded data structures are usually about
+20% smaller than the same data encoded as (compact) JSON or L<Storable>.
 
 The primary goal of this module is to be I<correct> and the secondary goal
 is to be I<fast>. To reach the latter goal it was written in C.
@@ -65,7 +68,7 @@
 
 use common::sense;
 
-our $VERSION = 0.06;
+our $VERSION = 0.08;
 our @ISA = qw(Exporter);
 
 our @EXPORT = qw(encode_cbor decode_cbor);
@@ -454,10 +457,10 @@
 There is no way to distinguish CBOR from other formats
 programmatically. To make it easier to distinguish CBOR from other
 formats, the CBOR specification has a special "magic string" that can be
-prepended to any CBOR string without changing it's meaning.
+prepended to any CBOR string without changing its meaning.
 
 This string is available as C<$CBOR::XS::MAGIC>. This module does not
-prepend this string tot he CBOR data it generates, but it will ignroe it
+prepend this string to the CBOR data it generates, but it will ignore it
 if present, so users can prepend this string as a "file type" indicator as
 required.