LARGE-SCALE PARALLEL GRAPH-BASED SIMULATIONS - MATSim

XML File, expat Structured Text File, Structured Text File, fscanf
159s 31s 36s
Table 3.1: Performance results for reading different types of plans file and approaches.
In the example, 6357250 is the vehicle ID, 0 in the first line shows the leg number, and
24875 is the start time of the plan in seconds (06:54:35). The start accessory ID and the end
accessory ID are 14584 and 14606, respectively. An accessory can be an activity location, a
parking or a transit stop. Duration of the leg is 1800 seconds (30 minutes). The 0 in the third
line shows the mode of transport (car). 8 is the number of the intermediate nodes between the
start and the end activity locations, and these nodes are lined up in the last line.
The performance is user-implementation dependent. One version of implementation keeps
each vehicle’s data in integers in an STL-vector while reading. When the vehicle is created,
the program accesses the values from the STL-vector. The code elements are given in
Figure 3.13.
Yet another version uses a C library function called fscanf to read chunks of data. The
data is directly stored into integer arrays similar to the STL-vector used above. Once the
vehicle is created, its variables are set using these integer arrays. A rough example code is
given in Figure 3.14.
Results
Table 3.1 shows the results for different reading approaches and for different types of the plans
file. The scenario used is the one explained in Section 2.5, i.e., around 1 million agents are
read. The numbers show the time for reading and for constructing agents. Once the agents are
created, they are inserted into one of the supplementary structures of the links, such as waiting
queues and parking queues. These queues are of the STL-multimap type.
Reading the same data from the structured text plans file gives better results by 80% relative
to the XML file version. Despite its lower performance values, XML is a promising technology
because of its benefits as given in Section 3.4.1.
An important remark to be made is that the lower performance values of XML come mostly
from the implementation inefficiencies, not from format itself: While expat parses the input
plans file, an object-oriented wrapper around expat inserts each person’s data (plans and the
other attributes) into an STL-deque. If the traffic flow simulator needs to read the next person,
the wrapper calls pop front() to get and to remove the first element from the STL-deque.
A problem resides here: The STL-deque is used in a way that it keeps the objects as opposed
to keeping pointers to the objects. When a pop front() call is made on such a container,
before deleting the element, the wrapper copies the element into a temporary variable. Then,
the element is deleted from the STL-deque and the temporary variable is returned (copied)
to the traffic flow simulator. If one used pointers to objects instead of objects themselves, not
only memory allocation would be done once and in an efficient way but also the pointers to
objects would be copied between different components via copying pointers instead of copying
the objects themselves, which that would result in less overhead.
3.4.4 XML vs Structured Text Files: Graph Data Reading
The graph data can also be kept in two different types of files. Nodes and links are defined by
either XML attributes or column-based numbers. The XML graph data file reading is the same
31