RomVault is capable of processing your archives and ROMs very quickly. Consider the following performance tuning tips below to allow RomVault to work as optimally as possible for your system.
Whenever possible its best to run RomVault from a fast NVME or SSD drive. RomVault periodically writes information to its cache file during a fix operation. The default behavior is to write the cache file to the same directory as the executable. This can be changed by editing RomVault's config XML file. For more information see the Advanced Configuration section.
RomVault processes fixes involving 7z archives by extracting the contents to a cache directory first then performing all fixes involving that archive in a batch. This behavior minimizes the number of times a solid 7z archive needs to be decompressed or recompressed. If no Cache ToSort is configured, then RomVault will use the Primary ToSort. If your Primary ToSort is on a slower drive or network share, you may experience sub-optimal performance with 7z archives. To prevent wear and tear on an NVME or SSD drive, you can also use a RAM Drive as a cache ToSort. For more information about the Cache ToSort, refer to the section on ToSort Directories.
Some collections like TOSEC may have extremely long path and file names. RomVault supports long paths as well as the \\?\ syntax, but Windows does not default to this behavior. Refer to the Microsoft documentation for instructions how to enable long path support.
RomVault supports mapped network drive locations as well as UNC paths. Mapped network drives on Windows tend to be preferred because they can easily be configured to automatically reconnect upon login. Although no official benchmarks have been conducted, some users report faster speeds when using a mapped network drive vs UNC paths. This may be due to the fact that a mapped network drive authenticates once instead of on every file access like when using a UNC path.
RomVault can move archives and uncompressed files quickly with a move operation instead of copy & delete. However, in order to perform this operation the source and destination must be on the same volume. For example, if you have an UnRAID array with a Downloads share and a Games share, you may want to create a rootshare so you can access both under the same drive letter or base UNC path. If you are moving files across shares or drive letters, a copy & delete operation will be used instead of rename.
UnRAID Note: The rename operation will not be used if the file to be moved resides on the cache pool and must be moved across shares, E.g. from Downloads to Games. To get around this and still use a cache pool, you should consider using a Downloads directory under your Games share so both the source and destination reside on the same share.
If you are using a SMB share and have performance issue with RomVault fixing files in large directories, you can try enabling case sensitivity. If a SMB share is case insensitive then Samba will do a filename search and match on passed names. For more information please refer to the Name Mangling section of the Samba documentation.
It is recommended to use case sensitive SMB shares with RomVault in your underlying filesystem is also case sensitive. Case insensitive SMB shares may result in an error while fixing due to changing character case of a filename.
If you are an UnRAID user, this setting can easily be changed to “Yes” in the SMB Security Settings tab of your user share.
Some Samba settings can greatly improve performance, especially for directory listing and traversal. Consider adding these SMB settings to your NAS configuration:
ea support = no store dos attributes = no
These settings will prevent Samba from writing and reading extended attributes used for legacy DOS permissions. Directory listing tests showed a 28% speed improvement.
Windows has a very aggressive real-time scanning service enabled by default. You may find better performance by adding your ROM and ToSort directories as exclusions.
One of the most common causes of poor performance is other disk activity. If you are having poor performance with scanning or fixing operations, try closing other programs that may be adding to disk load, for example torrents or indexing/hashing services.
RomVault uses a significant amount of RAM for its cache in order to perform much faster than a SQL database. Its recommended to have at least 1 GB of RAM per 1,000,000 ROMs managed by RomVault.
RomVault loads information from all DATs into memory which can use a significant amount of RAM. If you do not have enough RAM for the amount of DATs you have, you can use more than one instance of RomVault. For example all TOSEC DATs could be loaded using one instance and all Redump DATs with another. If you take this approach be sure that each instance is running from a separate directory so the cache files are not shared.