Performance profiling and debugger improvements desired

Performance profiling and debugger improvements desired

Post by Randall Pa » Fri, 12 Aug 2005 02:01:51


Do you use specific tools or debugging techniques to find out where you are spending
most of your time in your code?

I've been trying to find out why I've got performance problems in some really
complicated code that has lots of events flying around. I have some reactions to
BCB's deficiencies in this regard. Here is what I want:

1) A way to tell the de *** to set breakpoints on all the methods in a single class.

2) The de *** should be able to keep a count on how many times each method in a
class gets called from some time "t1" of my choosing to some time "t2" also of my
choosing. I want to say "start recording now" and then later "stop recording now".

3) A way to hit breakpoints ONLY if the method being called is being called from
outside of a class. I basically want to track entries into a given class.

4) A way to record the call tree each time some set of methods gets called. e.g. in
the previous example record the call tree each time a given class is entered by a
call from outside that class.

5) Skip over assembly when doing Step Into.

6) Skip over template code when doing Step Into.

7) Choose a list of classes that a special "Selective Step Into" should apply to.
Basically, ignore all classes not on the list and advance to the next execution point
that is in one of the classes of interest.

8) Stop on entry into a particular class ONLY if a certain other class or method is
in the current call tree. I basically want a quick way to find out if and how much a
call to method A in class X causes calls to method B in class Y.
 
 
 

Performance profiling and debugger improvements desired

Post by Team » Fri, 12 Aug 2005 02:58:31


"Randall Parker" < XXXX@XXXXX.COM > wrote in



Use a profiler, such as AQTime. Profilers are specifically designed for
exactly that purpose.


There is no option in the IDE to do that. You will have to set the
breakpoints manually.


Use a profiler for that.


The only way to do that is to analyze the stack directly and see if the
calling address belongs within the class's vtable. The de *** has no
options for doing that, and I do not know if any profilers can do it,
either. You may end up having to implement that inside your code directly,
setting a boolean variable that breakpoints can then check when needed.


By "call tree", I assume you are referring to a stack trace? A log of which
functions called each other to reach a certain point in the code.


You cannot Step Over when using Step Into.


That is a long-standing feature request that people have been requesting for
years. The current IDE does not implement it. It is unknown whether the
next version will implement it or not.


The IDE does not support that. If any third-party tools support it, I have
not heard of it.

find

You wil have to implement that manually. Again, by analyzing the stack
directly and then setting a flag that a breakpoint can then check for when
needed.

I suggest you direct your feature requests to QC ( http://www.yqcomputer.com/ ).


Gambit

 
 
 

Performance profiling and debugger improvements desired

Post by Pete Frase » Fri, 12 Aug 2005 04:02:59

As Remy has already said AQTime is the tool you need.
There is a trial available but it is well worth buying. It will
show you the call tree of functions so that you can see how
long each function took at any point in the hierarchy, even
recursive functions.
HTH Pete

"Randall Parker" < XXXX@XXXXX.COM > wrote in
 
 
 

Performance profiling and debugger improvements desired

Post by Chris Uzda » Fri, 12 Aug 2005 04:19:08

Randall Parker < XXXX@XXXXX.COM > writes:


I don't know how to do this other than manually.


This would be nice, but is usually a function of a coverage analysis
tool, and is oftentimes found in a profiler. I highly recommend
automatedQA's tools like AQTime for profiling and coverage analysis.


This is an interesting question. You might not like this suggestion,
but this is "doable" by having two classes. The outer one is used by
other classes, and it forwards each call into a corresponding function
on the "inner" class. Some benefits to this can be:

* the interface of the inner class can change without affecting other
classes using the outer interface. (The "bridge pattern")

* If you need to acquire locks, the outer class can do that, and then
call into the inner class, which does no locking. That way, the
inner class can call other functions in the inner class without
having to worry about "did I already lock? If not, do so now. Do I
need to unlock? Ok, my caller will do that." And so on. I believe
this is called the "Thread safe interface"

* If you implement this yourself, then you can set breakpoints on all
the functions in the outer class and know they're only being called
by other classes. (Since the inner class which does all the real
work only calls directly onto other members of the inner class.)


Nice idea.


You can't do that? Hmm, that's too bad.


If you step directly into a template function but it skips over the
template code, what should happen? Do you step in or not?

Do you mean to skip over the internals of the standard library, or
something more general?


Breakpoints are programmable, and I would assume that this may be
possible. One breakpoint can, for example, enable or disable another,
etc.

--
Chris (TeamB);
 
 
 

Performance profiling and debugger improvements desired

Post by Randall Pa » Fri, 12 Aug 2005 05:10:28

hris Uzdavinis (TeamB) wrote:


Can you start and stop AQTime logging while running an app? I want to turn on logging
right when I click on a particular UI button. Or I want to turn it on when I enter a
particular method. Otherwise one gets drowned in data.

I'll look into this. But I really think the debugger should be better. One gets
features in a debugger one doesn't get in a profiler and sometimes one wants to stop
and examine variables while trying to figure out why the flow of execution is
bouncing around so much.

I'm thinking about all these things because I'm debugging some logic someone else
wrote for notifying of changes across classes. I see logic problems which cause too
many notifications to bounce around. I want debugging and profiling features
simultaneously integrated together to enhance each other in a single session.


Yes, but in the case I'm thinking of the task of doing that would take days to set it
up. I'll figure out the answers in less time using other approaches.


Well, I'm finding myself in assembly. So I'm very disappointed with this debugger.
I've used much better ones in the past.

My problem is that I'm calling into a VCL lib which to set some property and that
eventually calls it to call back into my code with event change notifications. I want
to do a step that takes me from my code, all the way thru the VCL code, and then back
to some event notification routine all in one click. So Step Into would take me from
my code to my event notifier. Instead I find myself in assembly. How incredibly
unhelpful.


No, you don't step in. The idea here is a few fold:

1) I don't want to keep switching back and forth between Step In and Step Over. It is
error prone and requires too much mental effort that really shouldn't be necessary.

2) Sometimes a line has a few things in it and you want to step in on one piece of
what is on that line but not all of it. I end up taking code written by others and
breaking it up into a series of statements just so I can step into some stuff and
step over other stuff. I find this highly annoying and a waste of my time.

3) Some templates I'm using are not from the STL. I don't want to see into their
guts either. I want to declare them "not my code" and never see into them. I want a
"Step Into My Code Only" feature.

4) I really want to step only on MY code. Avoid assembly. Avoid templates. Just show
me source code lines I wrote. This is basic old stuff for a debugger. Well, what's
with Borland? BCB's debugger is lame.


More general.


I want this to be easy to do.

 
 
 

Performance profiling and debugger improvements desired

Post by Chris Uzda » Fri, 12 Aug 2005 06:26:45

andall Parker < XXXX@XXXXX.COM > writes:


I bought it back when BCB4 was "new", and can't really say for sure
what they offer now. But it was excellent then, and appears to be
even better now, if that's any help.


:) If you had breakpoints in your event handlers, then couldn't you
just click on "run" until it broke? Or are there too many to easily
set, or it would stop too often?


Well, if you want to debug template code, this feature wouldn't be all
that useful. It would have to be yet another setting, which takes
mental effort and so on. :) I don't think I'd like stepping over
template code if I click on "step into".


But they're two different desires, and you can't omit one without
negatively impacting someone else who likes it that way. Using the
mouse is tedious and error prone, but much less bad, IMHO, using the
keyboard shortcuts.


This is something I completely agree, but the problem isn't just in
"templates". Whenever you call a function, a slew of temporaries may
be created, as the arguments passed in are evaulated. I don't know
how they could provide such fine-grained control of the debugger to
skip all of the "preamble" that happens before you actually step into
a function, but it would be awfully complicated, especially since you
may actually wish to step into the construction of the arguments.


That would be nice, but it still wouldn't be enough. Given the
construction of temporaries for function calls, you could still spend
a lot of time stepping into setup of your own objects even if you
could disable entire sections of the std library or of even your own
code. You probably would find situations where you can't blacklist
your own code, but you still spend a lot of time stepping into it when
you don't want to.


I sympathize, but templates aren't really the problem. Afterall, you
could write templates yourself, and now you'd have a conflict of
interst. Should we be unable to debug template code?



But what you're asking is complicated, so there will naturally be
complexity in setting up the debugger to act the way you describe.
It's too specific to one problem to be a general solution that
everyone would want, I think.

--
Chris (TeamB);
 
 
 

Performance profiling and debugger improvements desired

Post by Atanas [AQ » Fri, 12 Aug 2005 06:51:13

> Can you start and stop AQTime logging while running an app? I want to turn


Hi Randall,

You can do it manually (there is Pause/Resume button) and we also offer
automated ways to do it.

You can see here the Actions and Triggers feature in AQtime :
http://www.yqcomputer.com/
where you basically select the routine that will trigger AQtime to start to
stop collecting results for you. This is probably the easiest way.

There are also ways to control AQtime from your own application

Cheers,
Atanas
 
 
 

Performance profiling and debugger improvements desired

Post by Jeff Wei » Fri, 12 Aug 2005 06:54:30


Is this a console only (no VCL) app or is it something you could use
CodeSite for? Although it take some time to add the code, it works
great for seeing whats happening without setting *any* breakpoints. I
wish I had purchased it years ago.

I am just throwing it out there in case you weren't aware of it :)

http://www.yqcomputer.com/

regards,

jeff
 
 
 

Performance profiling and debugger improvements desired

Post by Randall Pa » Fri, 12 Aug 2005 07:11:34

hris Uzdavinis (TeamB) wrote:

> :) If you had breakpoints in your event handlers, then couldn't you

Sure. Though in a couple of cases I was surprised by how certain calls into the lib
caused certain events to fire. I had to come to a point of suspecting that before
even knowing to set a breakpoint on the other side.


But I rarely debug template code. Mostly templates just get in my way in the debugger.


Yes, I get that. This is why I want better control over what the debugger thinks is
my code and what it thinks isn't my code.


Not saying it is easy to do. But we buy development tools because the tools separate
out what we want to pay attention to from what we want hidden away from us.


Still, what I'm asking for would reduce the distractions greatly. There's no ideal.
Just better and better.


I want to turn template debugging on and off. I rarely need to do it. I rarely want
to see templat code. In fact, in the last couple of years I can't think of a
situation where I did want to see what happened in a template. So all the template
code I've seen in the debugger for the last couple of years has just wasted my time.

I'd like to invoke a class list for my project and flip a switch to "opt in" mode.
Once in that mode I check those classes that I want the debugger to step into and
show me source code. Everything else which I don't select gets treated as invisible
to me.


I don't expect to get even 10% of what I ask for. But I ask for it all and hope
others will find reasons to support at least some of the suggestions.
 
 
 

Performance profiling and debugger improvements desired

Post by Randall Pa » Fri, 12 Aug 2005 07:13:03


It is a heavily GUI app.


Sounds good.


Never heard of it before.


I'll check it out.
 
 
 

Performance profiling and debugger improvements desired

Post by Andrue Cop » Fri, 12 Aug 2005 17:23:54


Seconded. Only problem is that it's *** ive. On the plus side playing
with it is not as obvious to your boss as playing Solitaire :)

--
Andrue Cope [TeamB]
[Bicester, Uk]
http://www.yqcomputer.com/
 
 
 

Performance profiling and debugger improvements desired

Post by Jeff Wei » Fri, 12 Aug 2005 21:38:32


It's really sad that Raize doesn't have a trial version of CodeSite.
In my opinion, if the $399.00 isn't going to break the bank just buy it.

Here is a list of the specific messages you can send to the viewer:

CheckPoint - Automatically named and numbered check point.

StringList - A list strings representing all items contained in the
specified list is attached to the message.

Object - A list of all published properties and their current values
for the specified object is attached to the message.

Color - The RGB and HSL values along with a sample of the specified
color are attached to the message.

Bitmap - An image of the specified bitmap is attached to the message.

TextFile - The contents of the specified text file is attached to the
message.

Memory - A hexadecimal view of the specified memory block is attached
to the message.

MemoryStatus - A list of system memory statistics is attached to the
message.

Window - The system details and styles for the specified window handle
are attached to the message.

Registry - The contents of the specified registry key are attached to
the message.

SystemInfo - A list of information about the system (i.e. OS version,
computer name, user name, screen resolution, etc.) is attached to the
message.

VersionInfo - The details of the applications version information
block is attached to the message.

XmlData - Xml data is attached to the message.

Collection - The properties of each item from the specified collection
are attached to the message.

EnterMethod - Entry point for a method. Used for grouping messages and
indicating program control flow.

ExitMethod - Exit point for a method. Used for grouping messages and
indicating program control flow.

CollapsedMethod - This message type is only used by the CodeSite
Viewer to represent a collapsed method.

CustomText - The contents of a custom data element formatted as text
is attached to the message.

CustomProperties - The contents of a custom data element formatted in
a name-value property grid is attached to the message.

CustomTable - The contents of a custom data element formatted in a
multi-row, multi-column table is attached to the message.

Custom - Base message type used in defining custom message types.
StackTrace - (.NET Only) The current stack trace is attached to the
message.

ComponentAsText - (VCL Only) A text representation of the VCL
streaming format for the specified component is attached to the message.

Property - (VCL Only) Message displays the current value of the
specified object's property.

Here is very simple example of how you use it (the _DEBUG stuff is
optional -- if the viewer isn't present the messages are not sent anyway):

bool TAppForm::OpenItemTotals()
{
#if defined(_DEBUG)
CodeSite->EnterMethod("OpenItemTotals()");
#endif

.
.

#if defined(_DEBUG)
CodeSite->Send(csmInfo, String("Param Order ID: ")...
CodeSite->Send(csmInfo, String("Param Item ID: ")...
#endif

.
.

#if defined(_DEBUG)
CodeSite->ExitMethod("OpenItemsTotals()");
#endif
}
//---------------------------------------------------------------------------
 
 
 

Performance profiling and debugger improvements desired

Post by Leroy Cast » Sun, 14 Aug 2005 07:07:32

On Wed, 10 Aug 2005 17:26:45 -0400, Chris Uzdavinis (TeamB)


I'm still using AQTime 3, but it has this feature so I'm sure the
current version does.

I'll second everyone else's 'thumbs up' for AQTime. It's great.
 
 
 

Performance profiling and debugger improvements desired

Post by Leroy Cast » Sun, 14 Aug 2005 07:15:20

On Thu, 11 Aug 2005 08:38:32 -0400, Jeff Weir


I'll second the CodeSite recommendation! I wouldn't want to program
without it - it can be a hugh timesaver.