Really short answer: No.
A few thoughts to help you out here:
- 15 Million is a decent size - but it isn't impossibly huge.
- I presume you are creating the index to better query it. So you care about the data inside of the table, right? So if you delete it you will have to just add the data again after the delete, now on a table with an additional index so that insert will be longer than it probably would have been.
- Would you get rid of all of the data? If so, I wouldn't try and do a delete statement in one big fell swoop on a table of that size. It will all be logged and it will be slow and will impact your server's performance potentially worse than an index rebuild. If you are truly removing every row - a Truncate would be better IF you were to do a delete first.
So basically - my thought process is - no don't delete first.. There are always caveats, though.
I answered like I thought you asked creating an index, not rebuilding. My answer doesn't change in fact it becomes simpler - you still don't need to do this. In fact the point of an index rebuild is to reorganize the index and remove index fragmentation. If you remove all the rows in your table before hand, it sort of defeats the need for the rebuild in a sense, right? So you can make your index rebuild faster or reduce the impact.
If in Enterprise Edition you can do this as an online operation to reduce the impact to the users. Watch transaction log growth, though.
You can choose to Reorganize instead of Rebuild. There are caveats here though - you aren't fully taking care of all levels of fragmentation, it can actually take longer, but it can have less of an impact.
You can change the degree of parallelism for the actual rebuild operation to take advantage of parallelism.
You can use a script like this one from Ola Hallengren to actually see if you even need to rebuild first and then only rebuild if you need to.
But no.. You don't ever need to empty the table first - unless you plan to empty it afterwards anyway.