Thank you Usul and Xenos!
I appreciate your fast responses and all the work the developers and supporters put into
navit, bringing us this great application -- I want to send this ahead of the test results below, to avoid any misunderstanding.
I've run a series of tests based on Xenos suggestion and the tickets #1158 and #1044, Usul seemed to refer to. The test setup is a WinCE 4.20 device (Blue Media BM6280), with
navit installed on the storage card and a minimal set of tools for performing and analyzing the test (memory gauge, task manager, editor for changing configs, file manager, a GPS tool) plus a few apps considered indispensible for productive use. The test destination lies 3 km south from my position as the raven flies, 3.9 km by street in car navigation mode with
route_depth="4:50%,6:1%,8:40000,12:10000,18:5000"First I tried the trick from #1044: creating a directory
navit.log to prevent writing of the log file. It did not reduce memory footprint of
navit. Obviously there is not much write cache used and IMHO the trick would only be effective when
navit is installed in the RAM of the device (what I would not recommend). If told were, I will gladly document this conclusions ...
Subjectively the GUI becomes a little bit sluggish with this trick, but this is not easy to measure, as GUI reaction seems to depend on GPS signals ...
Second I tested various settings for
cache_size. As ticket #1158 suggested successful tests with 256KB and 512KB, I started lower than Xenon's suggestion. Here the results of the test series:
- base line:
- With all tools installed and the memory gauge and task manager active, there are 34.11 MBs of free memory available for navit. (This is not tight, for comparison: Within this freespace a commercial car navigation app was operating for years over long distances (500-1000 km), still leaving 7-8 MB space for other applications.)
- navit without any cache_size limits has the following reproducible memory footprints some minutes after start up without any routing active and any user interaction (but the setting of a fixed position)
- 11.52 MB after getting a GPS position
- 11.70 MB when the same position is set as fixed position is set from a bookmark
- navit without any cache_size limits, after the successful calculation of the route to the identical destination
- start position via GPS: 24.43-24.63 MB total memory usage, or 13.11-13.32 MB pure routing memory footprint for a (trivial) short route (reproducible)
- identical start position, but as a fixed position set from a bookmark -- memory is eaten up much quicker than with a GPS position, navit reproducibly runs out of memory and crashes
- navit with cache_size=5MB (well actually cache_size=5242880)
- wildly oszillating between 8.69 MB to 11.87 MB while waiting for a GPS fix, GPS fix is not achieved over half an hour

After a few minutes waiting for GPS fix, navit would not respond anymore to user interaction on the map.
(This test was repeated several times for 20-30 minutes at 2 different locations, one having practically unlimited sky view (only <30° elevation to the north is obstructed). With the identical device and navit without a cache_size setting as well as another GPS application, GPS positions could be acquired within at most 2-3 minutes, often <1 minute, between the failed tests). - 7.13 MB, when quickly setting identical fixed position, no routing active
- routing from this fixed position: 24.07 total, or 12.55 MB pure routing memory footprint
- navit with cache_size=4MB
- Same behavior as previous test, when waiting for a GPS fix, but GUI starts to feel sluggish ...
- 6.45 MB, when quickly setting identical fixed position, no routing active
- routing from this fixed position: 22.15-22.35 total, or 10.45-10.65 (?) MB pure routing memory footprint
- navit with cache_size=3MB
- Same behavior as previous test, when waiting for a GPS fix, but GUI feels more sluggish, time span to set a fixed position before non-responsiveness is shorter ...
- routing from this fixed position: 17.63 MB total, or 5.93 (?) MB pure routing memory footprint
- navit with cache_size=2MB
- even interaction immediately after application start is not taking effect anymore
A similar, even shorter route leading north into a region with more detailed OSM mapping runs always out of memory.
I think a few conclusions can be drawn from these tests yesterday and today :
- the increasing detail of OSM maps over time continously rises the bar in terms of memory and processing power for navit, IMHO in an unhealthy manner, which will lead at least to resource hogging on "high-powered" devices ...
are there possibilities to reduce the amount of POIs, nodes, edges used/loaded for routing? - the "route graph" option shows that the Dijkstra algorithm evenly spreads in all directions, such touching a lot of map elements not even remotely having any relevance for the route. Besides RAM usage, this leads to a lot of IO and CPU usage. A "high-powered" device may not suffer from this, but routing with navit will nevertheless be much slower than with other navigation applications, potentially reducing the user base. So, some improvements in the routing algorithm might really be necessary!?
On the other hand, I do not have the slightest explanation, why setting
cache_size interferes with GPS reception, and why without
cache_size the identical route with identical start and end points works with a GPS position but fails when this position is set from a bookmark.
All in all, the results are baffling, partially even queer. To exclude the possibility, that there is some problem in the OSM mapping of the local area -- a kind of "black hole", leading to massive RAM usage, as soon as the area is touched by the routing algorithm -- it would be good, if somebody could reproduce these tests elsewhere.
Any tests I can run to clarify issues?