You may need this:

SELECT

--virtual file latency

ReadLatency = CASE WHEN num_of_reads = 0

THEN 0 ELSE (io_stall_read_ms / num_of_reads) END,

WriteLatency = CASE WHEN num_of_writes = 0

THEN 0 ELSE (io_stall_write_ms / num_of_writes) END,

Latency = CASE WHEN (num_of_reads = 0 AND num_of_writes = 0)

THEN 0 ELSE (io_stall / (num_of_reads + num_of_writes)) END,

--avg bytes per IOP

AvgBPerRead = CASE WHEN num_of_reads = 0

THEN 0 ELSE (num_of_bytes_read / num_of_reads) END,

AvgBPerWrite = CASE WHEN io_stall_write_ms = 0

THEN 0 ELSE (num_of_bytes_written / num_of_writes) END,

AvgBPerTransfer = CASE WHEN (num_of_reads = 0 AND num_of_writes = 0)

THEN 0 ELSE ((num_of_bytes_read + num_of_bytes_written) /

(num_of_reads + num_of_writes)) END,

LEFT (mf.physical_name, 2) AS Drive,

DB_NAME (vfs.database_id) AS DB,

--vfs.*,

mf.physical_name

FROM sys.dm_io_virtual_file_stats (NULL,NULL) AS vfs

JOIN sys.master_files AS mf

ON vfs.database_id = mf.database_id

AND vfs.file_id = mf.file_id

--WHERE vfs.file_id = 2 -- log files

WHERE (io_stall / (num_of_reads + num_of_writes)) >20

ORDER BY Latency DESC

GO

That's a DMV that collects overall latency. It is pretty safe to run on a production environment. Run it before the proposed change. After the change, run it again. Compare. You can also use perfmon to validate if you have an actual IO bottleneck or not.

Now, on my personal case though, I do prefer move an specific table (one that is being used a lot) and put that particular table on its specific FG, instead of creating bunch of files and move to a FG. That FG will reside on a new or different LUN, RAID10 if possible. This is the only way, as far as I know, that you can actually segregate IO usage per particular table.

If you create a bunch of files, put on a new FG, and place each file on different LUN or drive, not sure if MS-SQL will actually take advantage of that, as table's information will be mixed anyway.