Of the 8 hours, how much is placement, how much is route time, and how much is physical synthesis(if you have it on)? This can be found in the messages of the .fit.rpt(I would like these to be broken out more clearly...). If physical synthesis is on, it generally runs twice, so you'll have two sets of messages, and it's total time is usually a part of the total placement time, i.e. if physical synthesis is 3 hours and placement time is 4.5 hours, then only 1.5 hours is really spent placing. If you post the few lines from the .fit.rpt that say how long stuff runs for, that might help. (Also look at the physical synthesis messages on if they help, i.e. if combinational resynthesis improves the design by 0ps, then it's not doing anything besides chewing up compile time). With a better idea of where the time is spent, it would help devise the best way to attack it.
Also look at the Tools -> Advisors -> Compile Time Advisors
If it's only 55% full, can you put the Fitter Resource Usage Summary section of your report into a .txt file and attach it? That seems awfully low to be having problems, but 55% is a single number, when the fullness of a device really has many factors. What version of Quartus II are you using?
Finally, auto-sizing, auto-placing LLRs generally does not work out well. It's generally going to give worse results than a flat compile, which you're seeing, and generally is useful only as a starting point. Note that I don't think there any really good "auto-floorplanning" tools. Synplify's Amplify is a manual tool. Xilinx's Plan Ahead is manual. ASIC tools, as far as I know, are all manual floorplanning tools. From what I've heard, it's one of those things computer's just aren't that good at without spending tons of compile time, while humans tend to be pretty good, especially with intimate knowledge of the design. If you know the DDR2 core is along an edge, then put it in an LLR along that edge. If it then connects to some large procesing block, put that in an LLR next to it. You're basically floorplanning the connections. My experience though, is that it's not an easy thing to do(especially with hierarchies that are imbalanced in resources, i.e. have a ton of memory blocks but little logic, or something like that). Also, what goal are you trying to achieve. A bad floorplan hurts perfromance(which auto-size/floating LLRs will result in bad floorplans with lots of open space). A good floorplan can help by imparting knowledge to the placer on where things should go, how they connect, and limiting the solution space to a good solution, but I don't see huge gains either. If you're way off on timing, it won't have a dramatic affect.