There's nothing you can tune with that query. You're telling SQL to create a duplicate copy of the table, so it has to read the existing table from disk (if not already in the buffer pool), allocate the new table, update the allocation structures and system tables, process each row of the existing table, add those rows to the pages allocated for the new table, log the insert to the transaction log, repeat until all rows have been process, flush the transaction log records to the disk and then it's done.

You can't directly correlate a select into with disk speed, it's not the same as creating a duplicate of a file.

If you have performance problems, you need to identify the cause first. Are you bottlenecked on CPU? Is the server under memory pressure? Are there signs of IO contention? Is there severe blocking? Are the queries badly written? Is there inadequate indexing?

Maybe start with this, the first chapter gives some useful advice on profiling a server. http://www.red-gate.com/community/books/accidental-dba