[libtcas] About the new techniques in libtcas - file cache

milkyjing

Since I/O takes a considerable time in our rendering process, especially the first time to render a TCAS file, we should provide some methods to save the time and improve the performance.

When we have got free CPU time and the I/O is not busy, we can predict the most possible part (chunks) of the file, and read it into memory. Thus, we saved the time to read it when we require it later.

This concept is practical, because:
1. We are definitely sure that the CPU and I/O are not always busy even when we are rendering a TCAS file.
2. We can predict which parts are likely to be used in the following process, since the playback of a TCAS FX follows the sequence of the video frame.
3. So, we can do the I/O and other main memory operations simultaneously, thus, cut the I/O time from the total time usage. It seems that we can save about 3000 mm in the two tests used in this thread.

milkyjing

first access to a file (tcas_test_illusion)

initialization takes 3713 mm


total time for rendering 2084 frames 17768

I/O time 3731
Press any key to continue . . .

second access to the file

initialization takes 62 mm


total time for rendering 2084 frames 15226

I/O time 376
Press any key to continue . . .

third access

initialization takes 63 mm


total time for rendering 2084 frames 15553

I/O time 560
Press any key to continue . . .

-------------------------------

first access to another file (11eyes_op_720p.tcas)

initialization takes 3182 mm


total time for rendering 1733 frames 15522

I/O time 3122
Press any key to continue . . .

second access to the file

initialization takes 47 mm


total time for rendering 1733 frames 13369

I/O time 422
Press any key to continue . . .

-------------------------------

first access to another file (tcas_test_bezier)

initialization takes 5429 mm


total time for rendering 2000 frames 26099

I/O time 6160
Press any key to continue . . .

second access

initialization takes 125 mm


total time for rendering 2000 frames 20919

I/O time 1246
Press any key to continue . . .

third access

initialization takes 124 mm


total time for rendering 2000 frames 20577

I/O time 1031
Press any key to continue . . .

milkyjing

The implementation in the above thread is not so easy to achieve since the seeking of the potential chunks is a hard work if high performance is required. So we use another approach in the following.

1. Recall of the locality, which was used in the very beginning versions of TCFilter.
2. Read a considerable piece of file (e.g. 64MB), which then will contain a large amount of chunks, and again consider of the locality, in a certain duration, most of the chunks can be found in the buffer, thus, improve the performance.

milkyjing

So, how to implement the file cache concepts?

1. We must have a queue to store all the cached chunks, just like the frame cache does
2. Since we use libtcas_read_specified_chunk function to read the chunks from the file, we should provide a function to allow us read from the chunks cache queue.
3. The behavior of the chunk cache queue can somewhat be similar with the frame cache queue.
4. What information should be contained in the chunk cache queue?
    a) the offset of the chunk, which is used like an ID, and we use it identify whether a chunk has been cached.
    b) the buffer of the chunk, in another word, the real content
5. How to know which chunks to be pre-cached?
    a) We use indexStreams, and start at the very first valid frame minFrame.
    b) We will pre-read n adjacent TCAS frames' corresponding chunks (the chunks may not be adjacent in the file), or just m chunks (recommended), and cache them in the queue.
    c) The chunks cached will be consumed from the head of the queue (no matter whether it is the one we wanted or not), if one being consumed, one new chunk should be provided
6. How to provide and how to consume?
    a) libtcas_read_specified_chunk_ex_provider to pre-read the potential chunks, and cached them in the queue
    b) libtcas_read_specified_chunk_ex_consumer to actually get the chunk from the queue