Routino : Slim Mode Benchmarking

Introduction

The slim mode for the planetsplitter and router programs are separate versions of the programs that do not map the database files into memory. This allows the total size of the database to be larger than 2GB on a 32-bit system or use on systems where mapped files are not available or where the size of the mapped files counts towards the memory quota (some virtual machine environments). The need to seek within the file to read (or write) the data rather than allowing the operating system to optimise things will reduce the speed.

The information about the slim mode is presented below in an abbreviated form with no detailed descriptions. Unless there is a specific description of a reason for a change between versions it should be assumed that the description for the standard benchmarks also applies.

Database Generation

Time and Memory

The results for time and memory are presented below as a table and a pair of graphs.

Version	CPU Time (s)	Elapsed Time (s)	Max Resident Set Size (MB)
2.0	1421.15	1464.61	179
2.0.1	1423.44	1462.60	179
2.0.2	1410.94	1449.99	179
2.0.3	1408.08	1449.21	179
2.1	1418.77	1461.47	187
2.1.1	1143.19	1175.97	187
2.1.2	1088.75	1123.88	187
2.2	1160.34	1216.16	187
2.3	1147.53	1192.94	187
2.3.1	1136.84	1193.56	187
2.3.2	1154.33	1205.21	187
2.4	1174.06	1222.90	180
2.4.1	1158.52	1204.50	180
2.5	1140.91	1188.23	180
2.5.1	1275.88	1343.40	180
2.6	355.64	425.22	188
2.7	353.36	418.29	188
2.7.1	356.39	426.58	188
2.7.2	365.26	422.65	191
2.7.3	340.98	385.08	189
3.0	341.42	432.43	190
3.1 / 3.1.1	355.11	402.86	304

Version 2.0 ran without crashing although it crashed in the standard mode. This is probably because of a difference in which segment was kept in case of a duplicated segment (see below).

Version 2.6 had a large number of speed improvements, a lot of which are particularly applicable to slim mode. In addition to the file buffering which also benefitted the standard mode there is a larger memory cache of recently accessed objects (nodes, ways etc).

In version 2.7.2 the memory cache for slim mode was increased which is visible in these results only as a very small increase in memory used.

Version 2.7.3 and 3.0 has no significant changes to the planetsplitter so the time taken is the same.

Version 3.1 (same as 3.1.1) uses significantly more memory and slightly more time. This is because of the use of 64-bit nodes for OSM IDs.

Database size and contents

The size of the database is approximately the same for the slim and standard versions of the program so no results are presented here. Since version 2.4 the results have been identical. In previous versions it varied because the sort function gave different results for overlapping segments depending on the amount of memory used for sorting.

Routing

Time and Memory

The results for time and memory are presented below as a table and a pair of graphs.

Version	CPU Time (s)	Elapsed Time (s)	Max Resident Set Size (MB)	Number Routed
2.0	32.98	33.02	50	179
2.0.1	33.01	33.05	50	179
2.0.2	29.15	29.18	49	179
2.0.3	32.64	32.67	49	179
2.1	32.47	32.50	49	178
2.1.1	22.17	22.19	66	178
2.1.2	2.73	2.74	25	178
2.2	2.69	2.69	24	180
2.3	2.71	2.72	25	180
2.3.1	2.62	2.63	24	180
2.3.2	2.66	2.67	24	180
2.4	2.60	2.61	24	182
2.4.1	2.88	2.88	26	187
2.5	2.81	2.82	26	187
2.5.1	2.84	2.85	26	187
2.6	1.45	1.45	27	187
2.7	1.43	1.44	27	187
2.7.1	1.45	1.46	27	187
2.7.2	1.44	1.44	33	187
2.7.3	1.45	1.45	33	187
3.0	1.41	1.42	33	187
3.1 / 3.1.1	1.44	1.45	34	187

Version 2.1.1 benefited from the improvements in the standard mode of operation with no specific slim mode improvements but this does increase the memory used significantly.

Version 2.1.2 included a specific optimisation for slim mode by using more RAM to cache some data which greatly improves the time taken. The other improvement in this version is the same as for standard mode which reduces both memory and time.

Version 2.6 was also faster at routing, mainly because of the additional object cache that also helps the database generation but also for the same reasons as the standard mode.

Versions 2.7 and 2.7.1 made no changes to the performance.

Version 2.7.2 show an increase in memory usage due to the increased size of the memory cache but there is no change in the time taken.

Version 2.7.3 had no changes to the routing.

Version 3.0 has a very small reduction in time, possibly due to the parsing of the profiles files.

Version 3.1 (same as 3.1.1) has a slight increase in time due to the routing from both ends towards the middle.

Conclusions

The slim version of database generation uses only one third of the memory and the time taken is one third longer compared to the standard version. The saving in memory is considerably more than the increase in time.

The slim version of the router uses only one third of the memory but the time taken is about three times as long as the standard version. The tradeoff between time taken and memory used is much more balanced.