Quote:
Originally Posted by Xitix
I took a look at what VG is doing using FileMon (available from FileMon for Windows v7.04) and it highlights one huge inefficiency in VG and some areas it could be improved.

1. A lot of reads from mesh and texture files are in pairs. It reads a chunk of a file followed by reading a smaller piece of what it just read. This is an insanely dumb thing to be doing as a memory copy would be orders of magnitude faster. At least 100x faster in most cases with such small reads. A lot are also two adjacent reads of adjacent parts of the file that could be coalesced into a single read.

2. Music/sounds constantly re-read the same parts as needed when even a small cache of recently played parts would easily cut the number of reads by 75-90%. It also reads sequential parts a lot that could be coalesced into fewer reads but a cache would lessen the need/benefit for doing that.

3. Far too many small reads that could be coalesced into larger ones. Spend some effort to list all that needs to be read and coalesce those parts that are adjacent. For instance when peaking into a dungeon or building where a lot of related geometry and textures suddenly becomes visible and is loaded from the same file.

Alternate #3. For areas like a dungeon/chunk read the whole file in and grab the bits as needed from the copy in memory instead of doing 1000's of small reads from the file system to access every little object as it comes into view.

4. After trying to load an asset from a file that doesn't exist in doesn't cache that fact and tries to open it over and over and over. Here it was for a file named \Vanguard\bin\Chunk_n11_n9.int which it tried to open 40 times in a row.

5. The compiled vertex and pixel shader cache files are both read and written in 100's of little bits even when they are 233k and 2,892k here. Coalesce all those parts in memory into one write. Read it all and chop it up from the in memory copy for reads.

6. On shut down the large parts of the VGSettings.xml are written out sequentially one *BYTE* at a time. This is thousands of writes for a file that is only 54k. Again do all that parts stuff to a chunk of memory and do a single write to the file. At least on start up it's read in using three large chunks here.

--------
Fixing up the worst of these file read/write ineffeciencies would lesson a lot of the slowdowns in the game. Hitching on asset loading would be lessened and the game would load and shutdown faster.

OK. I had a coder respond to me on this. He read the post over the weekend and took the initiative to download FileMon and run some tests.

Sadly there is no miracle gain to had here, as the only line items that would provide anything is #6; and that gain is minimal at best. =/

I still believe we can optimize the sound code, and no doubt, there are other optimizations that need to be made. If I hear of anything else, I will let you know.</div> <div> __________________
Nino McHammer
Fires of Heaven
Veeshan

Weiterlesen...