Please consider editing your post and mark it as obsolete instead. Do you want to delete post?
Stepping in debug is slow (AS3)
Permanently deleted user
Created
Stepping while debugging seems a tad slow (0.2 seconds-ish). This is the case for even very small projects. Any ideas how I diagnose and fix this problem?
0.2 seconds doesn't seem to be slow :) In any case unlikely this can be fixed at IDE side. IDE simply sends "step" command to the fdb tool from the SDK that in its turn sends the command to the Flash Player, then Player suspends at new position, sends info back to fdb and IDE gets this info from fdb.
Stepping in IntelliJ is 7x slower than it is in Flash Builder.
I made a sample program to prove my observations. These are my results: Approximately 90 steps. Holding F6 (step over) to step through as fast as possible IntelliJ: 35 seconds (0.4s /step) Flash Builder: 5 seconds (0.05s /step)
I have the problem all the time. Some of my co-workers experience the problem once in a while.
FDB tool is embedded into Flash Builder, runs in the same Java VM, but in case of IntelliJ IDEA it is started as a separate OS process, so communication takes more time.
FDB tool is embedded into Flash Builder, runs in the same Java VM, but in case of IntelliJ IDEA it is started as a separate OS process, so communication takes more time.
If there are no legal or insurmountable technical reasons for this, would it be possible to provide an option to embed FDB? If there are risks to the user, I think it'd be OK to provide the option as long as they are articulated when the user selects the option. I know that in some cases I'd be willing to accept them for a faster debug experience.
I'm not a legal expert, but embedding fdb seems to be allowed. Unfortunately I'm not sure if/when we'll have anough time for this task. 0.4s per step is not that bad and hundreds of steps is not a usual use case.
I'm not a legal expert, but embedding fdb seems to be allowed. Unfortunately I'm not sure if/when we'll have anough time for this task. 0.4s per step is not that bad and hundreds of steps is not a usual use case.
I think the number of steps depends on what you're debugging. My project for the last few months has involved writing a container/component layout and rendering system that essentially replaces Flex's built-in system because it didn't handle our needs. I often find myself having to step through many layers of containers of containers of containers trying to figure out why component XYZ isn't in the right position or at the right size, where at each layer I have to step through many lines of many functions, being sure to step in or over at the right spot, often in repetitive code. Having even a 0.4s delay between each step slows me down significantly. More to the point, I become (a) impatient and "step ahead" (often to my detriment) and (b) numbed to the point that I lose track of where I am in the stack.
The 0.05s delay that Morten cites would be much more effective for me. Unfortunately for my debugging sessions, everything else about IntelliJ kicks FlashBuilder's butt, and so I'm firmly committed to IntelliJ.
Incidentally, one thing I've tried to do is to add Conditional breakpoints to help myself - I often know ahead of time that for function foo() that is called by every container, I am only interested in stopping when the container's frabble property's value is "flummox". So I set a condition on the breakpoint at foo() and hit "resume". This slows my program down a lot, but is a way around the stepping problem, when it works. I've found, though, that a lot of Conditionals can confuse the debugger and it starts missing breakpoints.
Another thing I do is to add Logging breakpoints - breakpoints with Suspend turned off but a useful logging message. This helps as well, but can also confuse the debugger.
So my ideal debugger would have these tools PLUS the speed of embedded fdb.
I'll go enter a request in YouTrack and reference this thread. That way it can at least get onto your radar.
Thanks for backing me on this one. I'm also in a position involving many steps using the debugger. 0.4s IS a long time and makes the IDE seem sluggish. Today I furthermore experienced delays as high as a second for each step.
0.2 seconds doesn't seem to be slow :)
In any case unlikely this can be fixed at IDE side. IDE simply sends "step" command to the fdb tool from the SDK that in its turn sends the command to the Flash Player, then Player suspends at new position, sends info back to fdb and IDE gets this info from fdb.
Stepping in IntelliJ is 7x slower than it is in Flash Builder.
I made a sample program to prove my observations. These are my results:
Approximately 90 steps.
Holding F6 (step over) to step through as fast as possible
IntelliJ: 35 seconds (0.4s /step)
Flash Builder: 5 seconds (0.05s /step)
I have the problem all the time. Some of my co-workers experience the problem once in a while.
FDB tool is embedded into Flash Builder, runs in the same Java VM, but in case of IntelliJ IDEA it is started as a separate OS process, so communication takes more time.
Pitty... It is fairly annoying. Better than the IDE crashing all the time though.
If there are no legal or insurmountable technical reasons for this, would it be possible to provide an option to embed FDB? If there are risks to the user, I think it'd be OK to provide the option as long as they are articulated when the user selects the option. I know that in some cases I'd be willing to accept them for a faster debug experience.
I'm not a legal expert, but embedding fdb seems to be allowed. Unfortunately I'm not sure if/when we'll have anough time for this task. 0.4s per step is not that bad and hundreds of steps is not a usual use case.
I think the number of steps depends on what you're debugging. My project for the last few months has involved writing a container/component layout and rendering system that essentially replaces Flex's built-in system because it didn't handle our needs. I often find myself having to step through many layers of containers of containers of containers trying to figure out why component XYZ isn't in the right position or at the right size, where at each layer I have to step through many lines of many functions, being sure to step in or over at the right spot, often in repetitive code. Having even a 0.4s delay between each step slows me down significantly. More to the point, I become (a) impatient and "step ahead" (often to my detriment) and (b) numbed to the point that I lose track of where I am in the stack.
The 0.05s delay that Morten cites would be much more effective for me. Unfortunately for my debugging sessions, everything else about IntelliJ kicks FlashBuilder's butt, and so I'm firmly committed to IntelliJ.
Incidentally, one thing I've tried to do is to add Conditional breakpoints to help myself - I often know ahead of time that for function foo() that is called by every container, I am only interested in stopping when the container's frabble property's value is "flummox". So I set a condition on the breakpoint at foo() and hit "resume". This slows my program down a lot, but is a way around the stepping problem, when it works. I've found, though, that a lot of Conditionals can confuse the debugger and it starts missing breakpoints.
Another thing I do is to add Logging breakpoints - breakpoints with Suspend turned off but a useful logging message. This helps as well, but can also confuse the debugger.
So my ideal debugger would have these tools PLUS the speed of embedded fdb.
I'll go enter a request in YouTrack and reference this thread. That way it can at least get onto your radar.
YouTrack issue created: https://youtrack.jetbrains.com/issue/IDEA-134520
Ok, thanks.
Thanks for backing me on this one. I'm also in a position involving many steps using the debugger. 0.4s IS a long time and makes the IDE seem sluggish. Today I furthermore experienced delays as high as a second for each step.
You're welcome!
Ouch. Are you able to use either of the tricks I mentioned above to reduce your need to step?
I haven't tried logging breakpoints. I'll try that tomorrow.