Samsung Galaxy S5 G900F (Snapdragon 801 running Android 6.01).Sony Xperia XZ1 Compact (Snapdragon 835 running Android 9).It’s not extensive, but given their relative difference in chipset, I think they’ll provide an adequately varied performance insight: Test devicesĬurrently the range of my own personal device lab, only extends to the following two devices. To benchmark the performance of tesseract, I’ve added a very simple test that runs OCR on the same 640×480 black and white test image, ten times in a row 1, and then outputs the average running time: Test Imageįull source of the test available here. Root /tesseract-3.05.02 # grep CXXFLAGS MakefileĬXXFLAGS = -g -O2 -std=c++ grep CXXFLAGS Makefile To note, in both cases the optimisation level of GCC was set to -O2: Version r18b: tesseract-3.05.02.DockerfileĪside from using different NDKs and a few minor changes to the configure flags, they’re pretty much alike.The docker files I’ve used for each version of the NDK is linked here: I won’t go into details about that project here, but feel free to check it out nonetheless. To build an Android compatible shared library of Tesseract, I’m using a homegrown build system based on Docker, aptly named Building for Android with Docker, or bad for short. In this post we’ll be looking at how it performs, with versions built by both compilers. One such dependency is Tesseract, which is a main part of the OCR pipeline of the app. In r18b GCC has been removed, in favour of Clang, so I decided I wanted to gauge any performance differences, that that change might have incurred. In the the process of moving an Android app project of mine, Camverter, off the now ageing version r10e of the Android NDK and onto version r18b, I had to rebuild some of its dependencies as well, in order to to maintain standard library compatibility. Here’s an interesting find, I came upon recently.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |