# Scenario B: Read-process cycle

## Introduction

This scenario will demonstrate an example of how the File Profile Analyzer was used on Pummel to help improve load times. In this scenario the File Profile Analyzer analyzer was used on XBOX 360 profile data to help discover a read-process cycle.

## The case

We loaded the profile data in the File Profile Analyzer which gave the following result:

Looking at the sum graph it is clear that the both the idle time (the red line) and the read time (the green line) are the most important factors in the load times, because they are above the other lines.

The seek time (the blue line) starts off reasonably heavy in the first 1.5 seconds where it accumulates to 1 second. After that however the seek time only increases about 0.8 seconds over the course of the remaining 10 seconds. The seek line is relatively flat and also shows fairly large amount of the line being dotted. The dotted lines indicate that the device does not spend any time on that kind of operations. The relatively low seek time combined with the fact that both the idle time (the red line) and the read time (the green line) are far greater than the seek and delay time (the purple line) indicate that we should not be solving at the seek times at this time.

Both the idle time (the red line) and the read time (the green line) are fairly steep and for a large part above the other lines. The fact that the idle time is for the greater part above all the other lines, combined with the fact that both the idle time and the read time shows 'a staircase pattern' indicates that the load is bound by a read-process cycle. The 'staircase pattern' is the steep line followed by a flat line. Note that the idle time means idle for the media from which data is read. Generally speaking this is because the CPU is doing some form of processing.

For example from second 5.3 to 6.3 there is a steep read (the green line) but a flat idle time (the red line). Whereas directly after that from second 6.3 to 7.8 there is a flat read time (the green line) but a steep idle time (the red line.)

The same staircasing pattern can be seen for:

- second 1.5-2.2 - read time, second 2.2-3.8 idle time
- second 3.9-4.2 - read time, second 4.2-5.3 idle time
- second 5.3-6.3 - read time, second 6.3-7.8 idle time
- second 7.8-8.8 - read time, second 8.8-10.2 idle time

To figure out which files are causing this behavior we first `click` somewhere in the sum graph in the 1.5-3.8 seconds interval and then `CTRL+click` the other intervals.

While `CTRL+clicking` on the intervals we notice that the interval between 5.3 and 7.8 is actually divided into two intervals. We only select the two parts of the interval giving us:

Looking at the overview we can see that one of the filenames is actually split up into two parts: `\data\xenon\bigs\rendering\boxer_1_big.ast` and `\data\xenon\bigs\rendering\boxer_17_big.ast`. This is caused by an inadequacy of the XBOX 360 file event format. If we had used the Simple Profiler this would not have happened. Nevertheless we can see that we are still accessing the same file, hence the two parts actually belong together.

So we select all the intervals to figure out which files cause the staircasing:

In the overview we can see the 5 entries that cause this behavior. We can see that both the boxers and the venues cause this behavior. So now we know what the problem is, and we know where the problem is. Unfortunately the File Profile Analyzer does not provide a solution for the problem so the next step requires some thinking on your part.

Apparently data is loaded and then processed. There are basically two solutions to this problem:

- Read and process data in parallel
- Preload the data in the front end GUI

We could to come up a way to read and process data in parallel. For example keep reading data sequentially while processing the data parallel from the previous read. This will hide the most part of the flat lines for both the idle time (the red line) and the read time (the green line), because other operations are occurring in parallel.

Or we could try to preload the data in the front end GUI, because there is not a whole lot of CPU power required there. This would even save more time for the front end to back end transition because the data is not even read from the drive anymore for that transition.

## Conclusion

Using the File Profile Analyzer provided the insight that the reads and processing for some files were heavily interleaved.

At the time of this writing the options for solving the read-process cycle have not yet been completed, hence the end results are not yet displayed here. This scenario is interesting though because Pummel is exploring a totally new way of loading data that will hopefully enable Pummel to have exceptionally good load times.

Feedback? Please provide us with your comments on this topic.
For more help, send us an email
© 2007 Electronic Arts. All rights reserved.