My navigation software
has a database
downloaded from OpenStreetMap
and converted by my
to my own binary format.
See also the software documentation
of the database handler.
This page tries to demonstrate the possibilities of my database handler, especially its speed.
The Database Speed Test is executed in the following environment:
CPU: ARM Cortex-A8 at 720 MHz
Memory: 256 Mb
Storage: USB pendrive (JetFlash Transcend 64GB, measured reading speed: 23.5 Mb/sec, filesystem: ext4)
The Database parameters:
Number of Entries: 6466561
Number of files: 51324
Full Size: 400 MB (uncompressed, indexed database)
Note that this test uses only the Name Database
Interpreting the results
The Speed Test implemented within the current Ducktor Navi software executes some basic
operations and measures their execution time.
The following operations are executed:
Click on the picture to see the larger one.
Instantiating the Database Handler class (see
the software documenattion)
Executing a query for the full database and repeating it again to measure the
cache efficiency (see Query on the picture)
Seeking for some (100) random Id values, and repeating the same seeks again
(see Seek by Id)
Seeking for some (10) predefined Names, and repeating the same operations again
(see Name Search)
At first sight, it seems fast enough for navigation. However, only the Name Database
similar result is expected for Node
and other databases too.
Instantiating the Database Handler
itself needs very short time, so it is not necessary to
hold a global instance of it. Just create if necessary, and drop it after use. (Note that its time
sometimes cannot be measured by the timer of Beagleboard, so zero can be displayed here.)
The first access needs more time for all cases, while the repeated access is significantly faster.
Note that it is not cached
by the software, it is done by the kernel
, and remains fast
after restarting the software.
However it is not tested here, but requesting consecutive entries needs very short time similar to
the repeated access, because it has high chance the requested pages has already been loaded in. It
means that loading map data (consecutive entries) during navigation can result in less than one
millisecond average access time. Later I am going to write a test case for this situation too.
The database handler needs very few memory: only some kilobytes are accessed during such a query.
the Smart Keyboard
which is the first
usage of this database handler.