Allocator<T>::uncompress is a performance nightmare

[dirkwhoffmann]

Uncompressing a snapshot can take multiple seconds if it contains a hard drive. The reason is that the implementation utilizes std::vector which is awfully slow, at least in debug builds.

TODO: Rewrite the code using good old C arrays.

[dirkwhoffmann]

Comparison between old and new code. Test case is a 138 MB snapshot shrinking down to 9.3 MB after compression:

• Debug build

  • Old code
    Uncompressing 9790563 bytes (hash: ff80197f)... 2.48 sec
Compressing 145308450 bytes (hash: f9ea0396)... 0.39 sec
  • New code
    Uncompressing 9790563 bytes (hash: ff80197f)... 0.17 sec
Compressing 145308450 bytes (hash: f9ea0396)... 0.40 sec

• Release build

  • Old code
    Uncompressing 9790563 bytes (hash: ff80197f)... 0.17 sec
Compressing 145308450 bytes (hash: cf0b5b96)... 0.11 sec
  • New code
    Uncompressing 9790563 bytes (hash: ff80197f)... 0.07 sec
Compressing 145308450 bytes (hash: cf0b5b96)... 0.14 sec

Pros:

• No more beachballing in debug builds.

Cons:

• The new code is more complicated because I have to deal with dynamic buffer resizing myself.
• In release builds, the 2.5x speed boost does not really matter as the 0.17 sec consumed by the old code is still acceptable.
• The old vector-based compression code outperforms my C-array-style code. This is interesting by itself as I have no idea how this is possible.

Overall, the cons outweigh the pros. Therefore, I'll revert to the old code.

[mras0]

Might be faster to just use this rather than the decode lambda:

vec.insert(vec.end(), isize(ptr[++i]), prev);

[dirkwhoffmann]

Might be faster to just use this rather than the decode lambda:

Indeed. This makes a huge difference. Very cool!

Debug build:

• Old: Uncompressing 9790563 bytes... 2.45 sec
• New: Uncompressing 9790563 bytes... 1.50 sec

Release build:

• Old: Uncompressing 9790563 bytes... 0.15 sec
• New: Uncompressing 9790563 bytes... 0.09 sec