Should I be concerned about the following message in the Run window? :
I/chatty ( 7764): uid=10079(com.homemy.myapp) Thread-67 identical 24 lines
I/flutter ( 7764): myDate.day is 16
I/chatty ( 7764): uid=10079(com.homemy.myspriteapp) Thread-78 identical 17 lines
Presumably your code that prints myDate.day is 16 has run multiple times in a short space of time so rather than fill the output up, it's been folded into that message.
Whether this is bad depends where the code is; if it's somewhere that is expected to run many times (like inside a loop) then of course it's fine. If it's somewhere you would not expect to execute multiple times, you may be able to understand why it is by adding a breakpoint and reviewing the call stack.
After two hours of debugging I can tell you not to underestimate that message. In my case, printing a dynamic value in a cycle, I got that message. I only found out after that I had a looping cycle. In fact, when I debugged the first cycle where I printed a string, there was an anomaly, that is, it stopped randomly without reason. This made me understand that it was the instructions already executed that created this anomaly even before I passed from the cause (loop of second cycle).
Related
I want to run my delphi program, but I need to see how many times a specific loop is executed. I remember in school when using Delphi 7 we used to set it so that when running it would only run 1 line at a time instead of run all of them at once. I can unfortunately not, for the life of me, remember how to do this.
How do you set Delphi to only run one line at a time and require you to step it forward before running the next one?
Run the program in the debugger. Typically you would start this by pressing F9, but that will set the program running. Instead you would use the Step Over action, with shortcut F8. Then each time you want to step over a line, press F8 again. As the name implies, if the line has a function call you will "step" over that call. To step into a function use Step Into, F7. When you do that the debugger will move to the first line of the function.
If you start the program in stepping mode, it might take you a while to reach the point of interest. Get there more quickly by setting a breakpoint with the F5 key, and by the Run to Cursor action, shortcut F4.
All of these actions can be found on the menu or the toolbar, but it is crushingly slow to use the mouse to step through code. That's why all half-way proficient developers use the keyboard shortcuts when debugging. It is way more productive and that really matters when debugging.
For more information, please refer to the documentation: http://docwiki.embarcadero.com/RADStudio/en/Overview_of_Debugging
F7 will execute one line (and will step into a subroutine).
F8 will execute one line (but will not step into a subroutine so actually many lines can be executed).
Shortcut keys are documented here.
You say that you need to know how many times a certain loop executes.
One way to do this is by placing a breakpoint on one of the lines inside the loop that is executed each time (not inside some conditional block or another nested loop) running your application in Debug Mode (F9 key shortcut) which would cause your program to stop once it reaches that breakpoint.
Then you use F9 key to step over that breakpoint to the next one and count how many times did your program stop at that specific breakpoint.
While the above approach is easy to setup it is not very friendly if you have loop with lots of iterations (a few dozens) as it can take you quite some time to count each iteration manually. Not to mention that you can easily miscount yourself.
So in order to avoid the above mentioned problems you can ask the debugger to help you with counting. How do you do this?
You do this in two steps.
In first step you place one breakpoint inside your loop like in the first example. But this time after you place it you right click on it and chose Breakpoint Properties from the Popup Menu. This will open Breakpoint Properties Dialog from where you can define different properties which affects what happens when the breakpoint is reached.
The property that you are interested here is Pass count.
Usually this property is used to break your program after specific breakpoint is passed for certain times.
But in our case we are not interested in stopping of our program but instead in counting the number of passes so you should set its value to be higher than the expected number of loop iterations so that this breakpoint won't cause your program to stop at all.
Then the next step is to add additional breakpoint on the first line which will be executed after the loop.
So your setup should now stop your program just after the loop and you can evaluate how many times was the first breakpoint (the one inside your loop) passed by moving your mouse cursor over it.
As you will notice the number of passes is shown as Pass count: X of Y where X is the number of times that breakpoint has already been passed and Y is the amount of passes that you specified in the breakpoint properties.
This second approach makes counting of loop iteration much easier especially when you have a few dozens or even a few hundreds of loop iterations.
But bear in mind that this approach can only be used to count the number of your loop iterations the first time the loop is used. Why?
Because the debugger is counting the number of breakpoint passes since the program start. So entering a loop again later would mean that the debugger would just continue counting from where it stopped last time.
You can however force the debugger to reset the counter by setting it to 0 and leaving your program to stop on it. After that you can again set the breakpoint Pass count property to some larger number.
NOTE: Resetting the breakpoint pass counter like explained above does needed you to step into one loop iteration so the number of total loop iteration returned will be lowered by one (the loop iteration that your program stopped in in order to reset the counter).
With all the talk about adding breakpoints and stepping through the code I want to offer another option: use a profiler.
With a profiler (like AQtime) you can easily find out how often which function or line in your program is executed without having to add additional variables or stepping through the code in a debugger.
If the only information you're interested in is the amount of times that a loop is executed, I think this is the cleanest option.
I have been struggling with parallel and async constructs in F# for the last couple days and not sure where to go at this point. I have been programming with F# for about 4 months - certainly no expert - and I currently have a series of calculations that are implemented in F# (asp.net 4.5) and are working correctly when executed sequentially. I am running the calculations on a multi-core server and since there are millions of inputs to perform the same calculation on, I am hoping to take advantage of parallelism to speed it up.
The calculations are extremely data parallel - basically the exact calculation on different input data. I have tried a number of different avenues and I continually run into the same issue - it seems as if the parallel looping never gets to the end of the input data set. I have tried TPL, ConcurrentQueues, Parallel.Array.map/iter and all the same result: the program starts out fine and then somewhere in the middle (indeterminate) it just hangs and never completes. For simplicity I actually removed the calculation from the program and I am just calling a print method, and Here is where the code is currently at:
let runParallel =
let ids = query {for c in db.CustTable do select c.id} |> Seq.take(5)
let customerInputArray= getAllObservations ids
Array.Parallel.iter(fun c -> testParallel c) customerInputArray
let key = System.Console.ReadKey()
0
A few points...
I limited the results above to only 5 just for debugging. The actual program does not apply the Take(5).
The testParallel method is just a printfn "test".
The customerInputArray is a complex data type. It is a tuple of lists that contain records. So I am pretty sure my problem must be there...but I added exception handling and no exception is getting raised, so have no idea how to go about finding the problem.
Any help is appreciated. Thanks in advance.
EDIT: Thanks for the advice...I think it is definitely deadlock. When I remove all of the printfn, sprintfn, and string concat operations, it completes. (of course, I need those things in there.)
Is printfn, sprintfn, and string ops not thread-safe?
Another EDIT: Iteration always stops on the last item..So if my input array has 15 items, the processing stops on item 14, or seems to never get to item 15. Then everything just hangs. Does not matter what the size of the input array is..Any ideas what can be causing this? I even switched over to Parallel.ForEach (instead of Array.Parallel) and same behavior.
Update on the situation and how I resolved this issue.
I was unable to upload code from my example due to my company's firewall policy, so in the end my question did not have enough details. I failed to mention that I was using a type provider which was important information in this situation. But here is what I figured out.
I am using the F# type provider for SQL Server and was passing around its Service Types which I suspect are not thread-safe. When I replaced the ServiceTypes with plain old F# Records, the code worked fine - no more deadlocks and everything completed without error.
I've tried every possible fields but can not find the number of times functions are called.
Besides, I don't get Self and # Self. What do these two numbers mean?
There are several other ways to accomplish this. One is obviously to create a static hit counter and an NSLog that emits and increments a counter. This is intrusive though and I found a way to do this with lldb.
Set a breakpoint
Execute the program until you hit the breakpoint the first time and note the breakpoint number on the right hand side of the line you hit (e.g. "Thread 1: breakpoint 7.1", note the 7.1)
Context click on the breakpoint and choose "Edit Breakpoint"
Leave condition blank and choose "Add Action"
Choose "Debugger Command"
In the command box, enter "breakpoint list 7.1" (using the breakpoint number for your breakpoint from step 2). I believe you can use "info break " if you are using gdb.
Check Options "Automatically Continue after evaluating"
Continue
Now, instead of stopping, llvm will emit info about the breakpoint including the number of times it has been passed.
As for the discussion between Glenn and Mike on the previous answer, I'll describe a performance problem where function execution count was useful: I had a particular action in my app where performance degraded considerably with each execution of the action. The Instruments time profiler showed that each time the action was executed, a particular function was taking twice as long as the time before until quickly the app would hang if the action was performed repeatedly. With the count, I was able to determine that with each execution, the function was called twice as many times as it was during the previous execution. It was then pretty easy to look for the reason, which turned out to be that someone was re-registering for a notification in NotificationCenter on each event execution. This had the effect of doubling the number of response handler calls on each execution and thus doubling the "cost" of the function each time. Knowing that it was doubling because it was called twice as many times and not because the performance was just getting worse caused me to look at the calling sequence rather than for reasons the function itself could be degrading over time.
While it's interesting, knowing the number of times called doesn't have anything to do with how much time is spent in them. Which is what Time Profiler is all about. In fact, since it does sampling, it cannot answer how many times.
It seems you cannot use Time Profiler for counting function calls. This question seems to address potential methods for counting.
W/ respect to self and #self:
Self is "The number of times the symbol calls itself." according to the Apple Docs on the Time Profiler.
From the way the numbers look though, it seems self is the summed duration of samples that had this symbol at the bottom of its stack trace. That would make:
# self: the number of samples where this symbol was at the bottom of the stack trace
% self: the percent of self samples relative to total samples of currently displayed call tree
(eg - #self / total samples).
So this wouldn't tell you how many times a method was called. But it would give you an idea how much time is spent in a method or lower in the call tree.
NOTE: I too am unsure about the various 'self' meanings though. Would love to see someone answer this authoritatively. Arrived here searching for that...
IF your objective is to find out what you need to fix to make the program as fast as possible,
Number of calls and self time may be interesting but are irrelevant.
Look at my answer to this question, in particular points 6 and 8.
EDIT: To clarify the point further, suppose the following is the timeline of execution of the program. Some of that time (in this case about 50%) is spent in an activity that can be removed, if you know what it is, such as needless buried I/O, excessive calls to new, runaway notifications, or "insignificant" data validation. If a random-time sample is taken, it has a 50% chance of occurring in that activity, and an examination of the call stack and/or program variables shows that it is doing something that can be removed. Then, if 10 such samples are taken, the activity will be seen on roughly 5 of them, regardless of whether the activity occurs in a few large chunks of time, or many small ones. The activity may be a few lines of code in a function doing something unnecessary, or it may be something much more generalized. Regardless, you recognize it, fix it, and get roughly a factor of 2 speedup. Call counts and self time contribute nothing to this process.
I am now trying to learn ruby-debug gem, but there are many jargons I am unable to catch up. Wondering if anyone could help with the explanations?
I couldn't find them in http://bashdb.sourceforge.net/ruby-debug.html either. The author assumed we already understand them (where can I learn about them anyway?).
For example here is a result of calling help frame in rdb. I helplessly don't understand all the items I bolded.
Move the current frame to the
specified frame number.
A negative number indicates position
from the other end. So 'frame -1'
moves to the oldest frame, and 'frame
0' moves to the newest frame.
Without an argument, the command
prints the current stack frame. Since
the current position is redisplayed,
it may trigger a resyncronization if
there is a front end also watching
over things.
If a thread number is given then we
set the context for evaluating
expressions to that frame of that
thread.
It's not Ruby-specific jargon; it's common to most all debugging.
Regarding stack frames
You've likely seen stack traces:
/usr/local/rvm/gems/ree-1.8.7-2010.02/gems/redgreen-1.2.2/lib/redgreen.rb:28:in `write': Broken pipe (Errno::EPIPE)
from /usr/local/rvm/gems/ree-1.8.7-2010.02/gems/redgreen-1.2.2/lib/redgreen.rb:28:in `output_single'
from /usr/local/rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:72:in `add_fault'
from /usr/local/rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:70:in `to_proc'
from /usr/local/rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/test/unit/util/observable.rb:78:in `call'
The full trace shows you the "call stack". The line at the top is where the exception was thrown, and the lines under it show the path through your code that the program took to get to that point. Each of those lines is a level in the stack, called a "stack frame". So, when an exception is thrown, the current stack frame is the top of the stack. If you move to frame -1 then you're moving to the bottom of the call stack. Think of the call stack like a stack of plates. When you call a function, you add a plate to the stack, and when you return out of that function, you remove a plate from the stack. Each plate is a frame. Since you usually end up calling functions within functions within functions, you end up with fairly deep call stacks, and walking up and down them can be useful in debugging, to evaluate local variables and state at each point in the call stack.
If you'd like to read up more on call stacks, Wikipedia has a nice article.
Regarding threads
Most all modern programming languages are multi-threaded, meaning that they can execute multiple code paths (almost) concurrently. So, imagine for example that you have a visual app, and you perform some expensive computation. Your GUI won't be able to react to any user input while that computation is running, which makes the application appear to be frozen to the user. You would solve this by running two threads: One thread would be responsible for accepting and handling user input and painting the GUI, and the other thread would be responsible for doing your heavy computation. Your compute thread could be stuck in an expensive loop and your GUI thread would keep running and painting the GUI.
If you are running a multi-threaded application, then you you have to select which thread you want to evaluate your debug commands (expressions) in, since each thread will be in different points of your code, and will have different call stacks and different local variables and state and such. This is the evaluation context.
However, I noticed that this is a Rails question, and Rails is (by default) single-threaded, so you shouldn't need to worry about threads.
Chris Heald gave a really fantastic answer. A couple of very small comments. Although Ruby Rails may be single-threaded (by default), depending on which kind of web server you run Ruby/Rails the overall program (webserver + Ruby/Rails) may no longer be single-threaded.
The comment:
Since the current position is
redisplayed, it may trigger a
resyncronization if there is a front
end also watching over things.
There are some debugging front ends that parse output looking for a source-code position in the output so that the front (such as the text editor GNU/Emacs) can show you where you were you are. (For GNU/Emacs it shows this in another editor window.) When you change to a different frame, that front needs to update the display showing where you are.
Although I know this to be the case for the Emacs and the oldish debugger front end ddd, I imagine you have the same thing going on if you are debugging from vim.
I am running into the following issue while profiling an application under VC6. When I profile the application, the profiler is indicating that a simple getter method similar to the following is being called many hundreds of thousands of times:
int SomeClass::getId() const
{
return m_iId;
};
The problem is, this method is not called anywhere in the test app. When I change the code to the following:
int SomeClass::getId() const
{
std::cout << "Is this method REALLY being called?" << std::endl;
return m_iId;
};
The profiler never includes getId in the list of invoked functions. Comment out the cout and I'm right back to where I started, 130+ thousand calls! Just to be sure it wasn't some cached profiler data or corrupted function lookup table, I'm doing a clean and rebuild between each test. Still the same results!
Any ideas?
I'd guess that what's happening is that the compiler and/or the linker is 'coalescing' this very simple function to one or more other functions that are identical (the code generated for return m_iId is likely exactly the same as many other getters that happen to return a member that's at the same offset).
essentially, a bunch of different functions that happen to have identical machine code implementations are all resolved to the same address, confusing the profiler.
You may be able to stop this from happening (if this is the problem) by turning off optimizations.
I assume you are profiling because you want to find out if there are ways to make the program take less time, right? You're not just profiling because you like to see numbers.
There's a simple, old-fashioned, tried-and-true way to find performance problems. While the program is running, just hit the "pause" button and look at the call stack. Do this several times, like from 5 to 20 times. The bigger a problem is, the fewer samples you need to find it.
Some people ask if this isn't basically what profilers do, and the answer is only very few. Most profilers fall for one or more common myths, with the result that your speedup is limited because they don't find all problems:
Some programs are spending unnecessary time in "hotspots". When that is the case, you will see that the code at the "end" of the stack (where the program counter is) is doing needless work.
Some programs do more I/O than necessary. If so, you will see that they are in the process of doing that I/O.
Large programs are often slow because their call trees are needlessly bushy, and need pruning. If so, you will see the unnecessary function calls mid-stack.
Any code you see on some percentage of stacks will, if removed, save that percentage of execution time (more or less). You can't go wrong. Here's an example, over several iterations, of saving over 97%.