In order to discount the natural performance drop of the debugger (which does need extra processing to perform its job), what you do is run your test game and notice the base of the screen has some yellow text (see manual for meanings). The F: symbol is your framerate at that momemnt. Now hit TAB and the FPS: symbol in the expanded view shows your new FPS. The differece in the values is the aproximate amount of drain the debugger requires from your system. Each system is different so values cannot be posted or announced in the manual. Use this differential to understand if it is the debugger or your level design that is causing the slowdown. I tend to keep the debugger screen off when testing, and if I hit slowdown, use the [ and ] keys to check scene polygon density, and if that is not it, I hit TAB to see if there is too much collision data or logic being demanded from that part of the level.
"We are the knights who say...eki eki eki fatang loopzoing, zanziga....ni"