At least on Windows, if the override size is > than 1 GB, the game will reduce to a crawl irregardless of your hardware. Thus, I listed the usual large files (WAV BAM, plus all area-graphic files, since TIS, WED, BMP and MOS must go in the same biff).
Fair enough, although normal WAVs are horrifically small, as are most WED, BMP, and MOS files. BIFFing them isn't going to "make your game faster" just because you're forced into BIFFing them with the TIS file, though.
I have no idea about the > 1 GB thing, though. I'd be more suspicious of atrocious numbers of files than file size, as the game surely maintains some sort of index (I don't see that they could do a fs check for x in the override for each and every resource loaded)?
(Not to mention .MVE files, which have to be biffed to work. Currently JZ handles this in a very unreliable way, since installs with INTERACTIVE and uninstalls with non-INTERACTIVE AT_* variants).
I don't necessarily agree with Sim and Cam that TP2 MAKE_BIFF is evil; I don't see it any differently than some horribly coded BAT garbage that's forced to run at exit. I do agree that BIFFing is, in most cases, completely pointless. I've never seen a mod include anything that's even decent enough to be worth the effort.
Once the files are accessed, there should be no difference in performance. Excepting odd behaviors in Windows, the only thing that should slow the game down is having to wait on the system to access each resource file separately, instead of accessing a single BIFF. The rest should be smooth sailing.
I don't. Given that there's never been a single complaint about the multitude of NPC mods that dump voicing or even song WAVs into the override, I think there's very little problem here.
Noted. I simply don't know when a WAV would be loaded (either the first time it plays, or pre-cached), unlike most graphics which are loaded with the area (TIS, BMP, MOS) or as-needed (BAM, some BMP, maybe some MOS). I also don't know how long they're retained, if at all (audio turnaround rates should be higher than images, I suspect).
EDIT: personally, if the audio file is small, I'd try referencing the sound from the creature file in one of the unused sound slots. That may get the game to load the sound early and hold on to it while the actor exists, and may reduce PlaySound() suckage. Maybe not...