The Adventure of Porting PeaZip to Linux ARM

[Arucard1983]

 Nice
I  hope this page will get more real test suport.

[Arucard1983]

Using a shell script, I could at least enable pea extraction in the XSDL emulator (with Gimp), since the Android Market had native support of many archive formats. The minimal support that I needed was to extract a PEA archive.

#/bin/sh
./pea UNPEA /sdcard/Download/*.pea . RESETDATE SETATTR EXTRACT2DIR INTERACTIVE

Save as unpea.sh and set as executable (At least it contains a graphic file browser that I could change file permissions).
The script should be in the same folder of pea program.
When I clicked the shell script, the pea file in the sdcard was extracted correctly

However, it is a long way to the full PeaZip works without hacks in the XSDL emulator, but a rooted Android or a chrooted ChromeBook should run the ARM version of PeaZip without problems.
But at least, it is the first workable program to extract PEA archives on non-rooted Android devices.

[Arucard1983]

With this little hack I could make the first benchmarks of the ARM port of PeaZip.

Selecting a PEA encrypted archive with 270 Mb and running on my Android Tablet with Pelya's XSDL emulator, and my computer, the extraction times was...
Tegra 3 1,6 GHz ARM : 3m 35 s
Pentium D 3,4 GHz x86 : 33 s
chrooted ARM on x86 : 3m

This means the PEA extractor was running at least seven times slower than x86 native version (non-patched), but it is a real beginning, since there's no native apps on Google Play that can extract PEA archives!

[Giorgio Tani]

Nice!
Probably performance differences on Pentium D are both due to emulation overhead and ASM optimized code being more efficient than pure Pascal replacement.

With more time, I would like testing compiling for pure Pascal and ASM on x86 for Win32 or GTK2 to see how much does it matter on performances - even if other factors are probably are relevant depending on the benchmark setup, i.e. disk speed and filesystem overhead if the test provides multiple small/fragmented files as input.

Another way to further isolate performance profile could be testing with and without hashing (advanced tab) and encryption (set by password screen) in order to include/exclude most CPU intensive algorithms while comparing the same disk/filesystem-level operations.