You are correct that using a different salt for each file will slow down encryption and decryption, in proportion to the number of files. But it is not useful to do so. An adversary is not helped if she knows that the salt is common to several files hashed with the same password (under the assumption that she can recognize a correct password with fair probability from one ciphertext, and cost dominated by PBKDF2). Both with common and different salt per file, the hard work for the attacker is finding the password; the cost of recomputing PBKDF2 for other files when salt is different will be comparably negligible.
Thus an option if to have the enciphering program generate the salt at random common to every files, and appropriate IV for each file (e.g. 48-bit file number, and 80-bit zeros; this is enough for $2^{48}$ files of $2^{84}$ bytes each, encrypted using AES-CTR); compute only one key using PBKDF2; and store salt and IV as header of each enciphered file. The deciphering program can cache the key in RAM for reuse when deciphering files with identical salt (it should not assume all files have identical salt, in case files separately enciphered are merged into the same directory).
When using other block-cipher operating modes such as CBC, CFB or OFB for enciphering multiple huge files, you may approach the limit of reasonable usage of one key. For this reason, or just for added peace of mind, you might want to have one key per file. This can be done while still amortizing the derivation of key from password over multiple files, by generating a common "slow" master key from password and master salt (e.g. random) for each encryption session, and a "fast" derived key from master key and secondary salt (e.g. file index) for each file, with both salts in the encrypted file's header. The "fast" derivation could be with PBKDF2 and a minimal iteration count c=1, or just one HMAC.
Also: you might want to consider scrypt instead of PBKDF2 (at least for the master key), for it provides better security for a given time overhead, as summarized in this table from the scrypt paper (2009):
Update (2020): state of the art has evolved. Bitcoin mining has shown that dedicated ASICs performing SHA-256 at high rate (220 TH/s) and efficiency (15 pJ/H) can become commercially available for few thousand US dollars. This makes it untenable to rely on PBKDF2-HMAC run on standard hardware for stretching of user-chosen passwords in high-security applications. Scrypt still stands strong, however the new best practice for password hashing is the winner of the password hashing competition, Argon2.