update

Performance.md

@@ -1,6 +1,7 @@
 ## Performance tips
 
-If you have a large number of datasets or snapshots its important to keep the following tips in mind.
+Depending on your situations, these performance tips may help a lot.
+
 ## Speeding up SSH
 
 You can make your ssh connections persistent and greatly speed up zfs-autobackup:
@@ -16,23 +17,26 @@ Host *
 
 Thanks @mariusvw :)
 
-## Buffering
+## Buffering and compression
 
-Also it might help to use the --buffer option to use IO buffering during the data transfer. 
+Also it might help to use the `--buffer` option to use IO buffering during the data transfer. 
 
 This might speed up things since it smooths out sudden IO bursts that are frequent during a zfs send or recv.
 
-## Less work
+If you have a slow link and compressible data, look at the `--compress` option.
 
-zfs-autobackup generate a lot less work by using --no-holds and --allow-empty.
+## Less zfs commands
 
-This saves a lot of extra zfs-commands per dataset.
+You can make zfs-autobackup use less commands per snapshot transfer by:
+
+* `--no-holds`: to prevent the hold/release commands.
+* `--allow-empty`: to prevent commands to figure out if a snapshot would be empty.
 
 ## Some statistics
 
 To get some idea of how fast zfs-autobackup is, I did some test on my laptop, with a SKHynix_HFS512GD9TNI-L2B0B disk. I'm using zfs 2.0.2.  
 
-I created 100 empty datasets and measured the total runtime of zfs-autobackup. I used all the performance tips below. (--no-holds, --allow-empty, ssh ControlMaster)
+I created 100 empty datasets and measured the total runtime of zfs-autobackup. I used --no-holds, --allow-empty and ssh ControlMaster.
 
 * without ssh: 15 seconds. (>6 datasets/s)
 * either ssh-target or ssh-source=localhost: 20 seconds (5 datasets/s)