Add performance notes.

README.md

@@ -18,6 +18,20 @@ Other platforms should also work fine.
 
 Tracy is split into client and server side. The client side collects events using a high-efficiency queue and awaits for an incoming connection. The server part connects to client and receives collected data from the client, which is then reconstructed into a viewable timeline. The transfer is performed using a TCP connection.
 
+### Performance impact
+
+To check how much slowdown is introduced by using tracy, I have profiled [etcpak](https://bitbucket.org/wolfpld/etcpak), which is the fastest ETC texture compression utility there is. I used an 8192×8192 test image as input data and instrumented everything down to the 4×4 pixel block compression function (that's a lot of blocks to compress). There are two scenarios that were tested:
+
+1. Compression of an image to ETC1 format.
+2. Compression of an image to ETC2 format, with mip-maps.
+
+It should be noted that tracy needs to calibrate its internal timers at each run. This introduces a delay of 115 ms (on my machine), which is negligible when doing lengthy profiling runs, but it skews the results of etcpak timing. The following times have this delay subtracted, to give focus on zone collection impact, which is the thing that really matters here.
+
+| Scenario |  Zones  | Clean run | Profiling run | Difference |
+|----------|---------|-----------|---------------|------------|
+|    1     | 4194571 |    1.22 s |         1.4 s |    +0.18 s |
+|    2     | 5592812 |    1.35 s |        1.52 s |    +0.17 s |
+
 ## Usage instructions
 
 #### Initial client setup