No suggestions at all?
There must be a way to do this. My hunch is that debugging slowdown is
related to the amount of user code that is being invoked. So the more
custom code you execute the more you'll see the slowdown. The android
frameworks themselves don't seem to be influenced by this; otherwise
more people would be complaining...
Pepijn
On 21/10/2011 17:36, Pepijn Van Eeckhoudt wrote:
In my project I've implemented a custom view that does a substantial
amount of processing when rendering itself. When I attach the debugger
to my application I'm experiencing so much slowdown that the
application is essentially not useable anymore. Due to the increased
time taken by certain methods gestures are no longer recognized
correctly and interaction with the view no longer works due to this.
I've profiled my view with and without the debugger attached and it
looks to me like every single method call has at least a fixed amount
of method call overhead when the debugger is attached. Since the code
in question calls a large number of very short 'getter' methods quite
a lot the total slowdown is quite extensive. My hunch is that this
type of code suffers the most from the 'attached debugger cost' and
since this is probably atypical code most people don't experience this
problem in their applications.
My question is if there's a way to improve this situation. Changing
the code is not really an option; the code in question is part of an
API that I cannot easily change. Is there perhaps someway to exclude
certain classes from being 'debuggable' or something like that?
Pepijn
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
