Given that it sounds like you have some relatively fast line following working, you must be generally doing it right, but this approach seems strange to me. The point of PID is to get your error to zero as quickly and stably as possible, so I expect the center line to be at an error of zero and your left and right extremes to correspond to something like -1500 and +1500. When doing line following with differential-drive robots, I have used the result of the PID computation as a speed differential parameter, so that the motor speeds become:
speed_differential = P*error + D*delta_error;
left_motor_speed = MAX_SPEED - speed_differential;
right_motor_speed = MAX_SPEED + speed_differential
Note that you have to make sure you get the signs right so that the robot turns in the proper direction when it's not over the center of the line, and also note that I would add some code to keep the motor speeds within the range of 0 and MAX_SPEED.
I know this is sort of a tritely obvious statement, but you cannot make a line follower arbitrarily fast; at some point, it either won't be able to react quickly enough to hold the line on sharp turns or it won't have enough friction to keep from skidding on the turns. Assuming your speed is not limited by your motors, it will then be limited by things like the friction of your tires and the responsiveness of your system. One problem with going to bigger wheels is that while your max speed goes up (which makes following the line harder in itself), your ability to accelerate goes down (you are trading wheel torque for speed), which can limit your robot's ability to quickly respond to to the course.
Here are a few other miscellaneous thoughts:
1) How far in front of your wheels are your sensors mounted? The farther out they are, the more advanced warning you get when a sharp turn is coming, which in turn means you can go faster and still have time to detect and react to turns. If this isn't intuitively obvious to you, just consider how fast you would be be comfortable driving if your visibility was restricted to 20 feet.
2) I expect you'll need a bigger P value than 0.17 to hold the line while moving quickly around sharp turns.
3) When you time your main loop, I suggest you do it once with your serial prints there and once without it. I would not be surprised to find out that the serial prints slow your main loop down by a non-negligible amount, depending on how many bytes you are printing and at what baud rate. For example, sending a 14-byte string like "error = -1773" at 9600 bps (as seems to be the default in a lot of sample sketches) will delay your main loop by approximately 15 ms and limit your update rate to something like 70 Hz, which is not very high.
4) Working with floats on an AVR generally pretty slow and not necessary for PID algorithms. I suggest you modify your code to use only integers. For example, you can rewrite 0.17 as 17/100, so your P term would become:
P = 17 * error / 100;
If you do switch to integers, however, make sure your calculations don't unexpectedly overflow!
5) If you are not powering your motors with a regulated voltage source or using encoders, tuning your PID constants will be harder because your robot's speed will be changing as the batteries discharge. Well-tuned constants might start behaving poorly as the robot's batteries run down, at which point maybe you'll retune it only to find that now it doesn't work with freshly charged batteries.
6) Keep your robot's tires clean! When you are running a course near the limit of what speeds are possible, dust build-up on your tires will lower their traction and cause the robot to start behaving differently. In general, the key to tuning PID parameters by trial and error is to hold all other variables, like maximum motor speed and tire traction, constant. If these things are changing while you are tuning, it becomes difficult to discern the effects of the tuning from the effects of the other variables.
7) Are you using our QTR Arduino library to get the line position/error? When doing PID, it is important to have a good, accurate, monotonic error function that offers enough resolution. If you are just looking at the four sensors to say that the line position is either 0, 1, 2, or 3 based on which sensor sees the most, you will not have very good results compared to using the analog readings of all the sensors to get a line position between 0 and 3000.