I found my project on the Google open-source community, it is called Zopfli is a compression library. This is how Zopfli is describe "a compression library programmed in C to perform very good, but slow, deflate or zlib compression". Zopfli can be found in Google open-source [https://opensource.google/projects/zopfli] or Github [https://github.com/google/zopfli]. Also, to understand more about this program I did some research and found this website [https://ariya.io/2016/06/using-zopfli-to-optimize-png-images] that explains very well how to compile and optimize images.
For testing, I found this website [https://www.sample-videos.com/download-sample-png-image.php] to get all my sample images. I decided to use 5 images to do the test with different sizes: 200kb, 1mb, 5mb, 10mb and 20mb.
First, I git clone the repository to the AArch64 Israel server and then proceed to follow the readme instruction from the GitHub page to build it.
These are the results I got after testing in our AArch64 Israel server:
For my testing, I will be using the 1mb and 5mb image to do the benchmarking. After adding the -pg option into our Makefile to run gprof to profile. I got these results:
Changing the Makefile to add -pg option:
1mb
5mb
Then running the gprof -p zopflipng gmon.out > test.txt command:
1mb
5mb
As we can see from both test ZopfliFindLongestMatch, BoundaryPM, encodeLZ77(uivector*, Hash*, unsigned char const*, unsigned long, unsigned long, unsigned int, unsigned int, unsigned int, unsigned int) and ZopfliUpdateHash takes a significant amount of time.
Let's see if for x86_64 will behave the same as for AArch64:
I will be using the school server xerxes to do the testing and see what is the difference between both architectures.
First, I git clone the repository into the xerxes server.
After that, I proceed to do the same testing before modifying the Makefile to add the -pg option. Using the same command time ./zopflipng sample.png sample_test.png, these are the results that I got:
Same as AArch64 I will be using 1mb and 5mb to do my testing. These are the results I got after adding the -pg option on the Makefile:
1mb
5mb
Then running the gprof -p zopflipng gmon.out > test.txt command:
1mb
5mb
The same case in AArch64 for both test ZopfliFindLongestMatch, BoundaryPM, encodeLZ77(uivector*, Hash*, unsigned char const*, unsigned long, unsigned long, unsigned int, unsigned int, unsigned int, unsigned int) and ZopfliUpdateHash takes a significant amount of time.
From what I can gather looking at the Makefile the feature flag control use is -O3, so I decided to experiment and change this to -O2 and -Ofast. I will be using the same 1mb and 5mb images mention for both architectures.
Aarch64 - israel
Using the gprof command:
-O2
1mb
5mb
-Ofast
1mb
5mb
X86_64 - xerxes
using the time ./zopflipng sample.png sample_test.png command to get the following results:
Using the gprof command:
-O2
1mb
5mb
-Ofast
1mb
5mb
The reason why I decided to use -O2 and -Ofast is because -O2 enables almost all safe optimization and -Ofast optimizes for fast execution. I wanted to compare it to the -O3 which enables aggressive optimization which was the default flag control on the Makefile. From the results gathered we can see that the difference is not that much from the different controls flags used, I think this might be because of how the program works.
But from the experiments, I gather that ZopfliFindLongestMatch takes a lot of execution time from all the experiments which made me curious to know why. I will be experimenting with this component in the next Stage 2 of this project.
Note:
As we can see from the results, this compression tool is very slow compare to others. I will be experimenting with this program and post the results as I go on.
Since this blog post is already long enough, I will be making another post summarizing my gatherings and linking some websites that help me do this optimization and why I decided to use some of the commands shown.