Cleanup & optimize performance of IO (switch to libspng)

[eWert-Online]

This PR is an effort to switch from libpng to libspng.
This doubles the performance of tiff, bmp and jpg (probably webp and avif too).

The performance of png sadly drops by ~200ms (edit: ~100ms).
This is because the encoder of libspng runs much faster compared to libpng when given a single byte array.
Because png was the only format which didn't use the bigarray, but the row pointers, it now is a bit slower.

The encoder of libspng is not yet released officially, so maybe there are also some pending performance optimizations... 😄

Using libspng also reduced the binary size by ~100kb.
In the future, we could also think about using miniz instead of zlib. It is also lighter and in some cases faster than zlib.

The big advantage that we get with this rewrite, is that all io implementations now use a bigarray to store and read their data. (Also we only have 1 PNG implementation now instead of 2).
So implementing something like #53 will probably get a bit easier.
We could also think about giving ocaml / reasonml users (me 😄 ) the ability to get the raw bigarray data out of the io functors.

@dmtrKovalenko What do you think?

Todo

• cross platform tests (windows and linux)

Performance Benchmarks

BMP:

JPG / JPEG

PNG 😞

TIFF

[eWert-Online]

@dmtrKovalenko Do you have any clue, why the windows pipeline gets an EACCES error?
Edit: It works on my local windows machine 😄
Edit 2: It could be related to this: esy/esy#1347
Edit 3: I guess it is more likely this issue: esy/esy#1083

[dmtrKovalenko]

I'll spend some time on weekend with this

[dmtrKovalenko]

Thanks for this, but I want to understand how having 1 implementation will help to implement buffers? Buffer will always be the encoded array data that we need to decode using specific codec, right?

So implementing something like #53 will probably get a bit easier.

Actually this type of lib where we are fighting for performance having optimizations like using raw pointers data without any data copying makes sense as for me, because making us as fast as possible. WDYT?

[eWert-Online]

I just realized that I had an error in my thought process.
I thought we could just dump the data given from the buffer directly into the bigarray. Now I realize, that we still have to run it trough the decoder of the given type 🤦
So we could still use raw pointers in theory.

I still think libspng is an optimization over libpng in terms of speed though.
If the drop of ~100ms is your only concern with this PR, I think there are still some perfomance gains on the table I didn't yet explore, because I wasn't sure if you would be open to this change in general.

[dmtrKovalenko]

Yeah I think that we can merge it but left 2 different decoders only for benchmarks 🙈

[eWert-Online]

Yeah I think that we can merge it but left 2 different decoders only for benchmarks

I am not sure I understand this correctly. You want to have libpng and libspng at the same time?

[dmtrKovalenko]

Oh my gosh yeah that is not an option -__- I`ll get back to this code in a few hours with more fresh mind to figure everything out

[eWert-Online]

Well...let me first take a look, if I can optimize the performance of the PNG IO a bit further.
Maybe even making it faster than the one we had before 🙂
Currently decoding and encoding with libspng is faster than with libpng. The only thing slowing us down is that we are reading from ocamls bigarray with all its boxed data.

[ManasJayanth]

re: Windows
Can someone try this nightly build and let me know if it still fails?
0.6.11-19279b

https://www.npmjs.com/package/@esy-nightly/esy/v/0.6.11-19279b

[dmtrKovalenko]

@ManasJayanth doesn't work https://dev.azure.com/dmtrkovalenko/odiff/_build/results?buildId=285&view=results basically get back to downloading esy@nightly here

[ManasJayanth]

@dmtrKovalenko In the build logs you linked, I don't think it's using the nightly I suggested. Am I missing something?

[eWert-Online]

@dmtrKovalenko
I made soma adjustments. I mainly moved from a double nested for-loop for the x and y axis to a single loop.
We now have equal performance for png with the main branch:

(main is the first one)

We are currently still incrementing x and y.
If I am not mistaken though, I think we can compute everything from the loop offset. Definetly something I want to investigate in the future.

[eWert-Online]

@dmtrKovalenko
Did you find time to look at this yet? 🙂
Is this approach something you could imagine moving forward with?

[dmtrKovalenko]

Sorry for so long delay, I had pretty busy period several months. I will take a look and merge this PR until the end of this week.

Honestly, I Was scared on the amount of code to read (the new deps) 😔

[dmtrKovalenko]

Thanks! Once again I am sorry for so long review