[Scummvm-cvs-logs] CVS: scummvm/scumm/imuse_digi dimuse_bndmgr.cpp,1.1,1.2

Max Horn fingolfin at users.sourceforge.net
Tue Jan 6 17:09:13 CET 2004


Update of /cvsroot/scummvm/scummvm/scumm/imuse_digi
In directory sc8-pr-cvs1:/tmp/cvs-serv24827

Modified Files:
	dimuse_bndmgr.cpp 
Log Message:
add FIXME comments at the two worst spots, speed wise (about 80% processor time or more are spent in these places for me, waiting for disk I/O)

Index: dimuse_bndmgr.cpp
===================================================================
RCS file: /cvsroot/scummvm/scummvm/scumm/imuse_digi/dimuse_bndmgr.cpp,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- dimuse_bndmgr.cpp	6 Jan 2004 17:28:29 -0000	1.1
+++ dimuse_bndmgr.cpp	7 Jan 2004 01:07:37 -0000	1.2
@@ -48,6 +48,17 @@
 		return false;
 	}
 
+/*
+ TODO / FIXME
+This is another spot were lots and lots of time is wasted, because the same data is read over
+and over again from the disk. Disk I/O is *slooow*.
+This function by itself actually isn't what is really slow - normally we would call
+it once and then be done with it.
+However, for whatever strange reasons, the higher level code constantly keeps creating
+new BundleMgr, uses them to open a file, play a piece of sound, then delete the BundleMgr.
+Repeat ad infinitum -> extremly slow.
+*/
+
 	tag = _file.readUint32BE();
 	offset = _file.readUint32BE();
 	_numFiles = _file.readUint32BE();
@@ -100,6 +111,13 @@
 		warning("BundleMgr::decompressSampleByIndex() File is not open!");
 		return 0;
 	}
+
+/*
+FIXME / TODO
+ This function is a major speed hog. It re-reads the same data over and over and over again.
+ Disk I/O is about the slowest thing on any modern computer. We used to cache all this data,
+ with good reason... this will have to be done again.
+*/
 
 	_file.seek(_bundleTable[index].offset, SEEK_SET);
 	tag = _file.readUint32BE();





More information about the Scummvm-git-logs mailing list