Revision as of 16:40, 10 December 2015

Exercise 8: Profiling

Goals

• Identifying bottleneck functions in a code segment

Debugging often involves finding the function which performs poorly - in terms of computation time and/or memory resources used. For the code to perform as desired , fixing the poorly performing function may often lead to a simple solution.

Exercise 8 in pretty straightforward with the main function calling two functions - doStuff() and doMoreStuff() . Both functions are called one after the other for two minutes. Our goal is to find how much time is taken by each function in the two minute run. One solution a programmer may think of is to keep track of time taken by functions in some flag variables using System time, but this method does not scale up for many function calls. Since the tutorial is for "debugging", we will not making any changes to code but will be using a profiling tool - Jvisualvm [1] which is a bare bones profiler with basic functionalities and is freely available.

Steps for exercise

1. Insert a breakpoint on the while statement in main method
2. Launch JvisualVM. All running java applications are shown in the in Applications Tab (left margin) of JvisualVM. Double Click to select E8PerceivingPerformance. Go to the profiler tab and click the CPU option. Note Click on the settings checkbox on upper right corner of Jvisualvm. In CPU settings , make sure the class being profiled is net.imagej.trouble.** instead of net.imagej.trouble.visible.** -
   
3. Switch to Eclipse and resume the execution of code
4. Wait for the stipulated time , twiddle your thumbs. Or you can switch to JvisualVM and see how much time is taken by each of function in real time.
5. Example output

Take Home Point

1. Use a profiler to find the function which takes more time.

Exercise 9: Multiple threads

Developing codes may often involve using multiple threads instead of sequential execution of statements. New threads may be spawned anytime when required. Essentially, threads should be used to run independent processes but if threads work on the same process there is no guarantee of execution of statements in different threads in a particular order.

E9 exercise on multiple threads focuses on this issue and also highlight an additional property of breakpoint that can be helpful in debugging program (Stop Virtual Machine).

Even though no code changes, sometimes debugging affects code execution. The Exercise 9 creates two parallel processes which are interdependent on each other. Each process throws up an error if the other process introduces a delay more than one second. So pausing for more than one second ,while debugging the program throws up an exception. So the act of debugging introduces errors in this case.

Steps for the exercise

• Run E9 with no breakpoint. Note that it works fine
• Now set a breakpoint in the “getName” method of either the Even or Odd LonelyRunnable
• Set the breakpoints property to “Suspend thread”
• Debug E9. After hitting the breakpoint, wait for a few seconds. Eventually you should see that a different thread is paused and “Expecting Exception”.
• resume the threads and see the stack trace.
• Now modify the breakpoint and tell it to suspend VM instead of just the thread.
• Debug again. When you hit a breakpoint, make sure you resume the VM and not just the thread.

Takehome point

• In case of multithreaded programming, stop the virtual machine at the breakpoint to freeze the state of all threads.

Setting a breakpoint on an exception

Hinerm (talk)

Exercise 2 - Ellen's Questions

Sorry guys... can you just clarify the final part of this exercise? I get the point of expressions - just not necessarily how to implement them correctly and then go through the debugging process... I'm missing something here...

"To complete this exercise: 1. Write an expression that calls the size() method of our list. 2. Write a 2nd expression that evaluates to the value of the index variable"

For these two steps... wording is weird and confusing - so I'm not sure exactly what I need to do... (note: this could just be an Ellen-exclusive issue)

maybe another image - snapshot - would be helpful here?? something a bit more concrete - since this is really the point of this exercise - expressions...

Etarena (talk)

Response from Mark

There's a line that's like "any number of Java expressions".. before this there should be a robust description (and links, including examples) of precisely what java expressions **are**..

Hinerm (talk)

TODO: Emphasize the utility of Exception Breakpoints - that we don't need to know where the failure occurred

Hinerm (talk)

Exercise 3 - Ellen's Questions

Sorry - again... maybe because it is 'me'...

Can you give me a concrete conditional statement as an example in the conditional breakpoints example step 5???

As a first-first-first timer... I have no idea what to even write! Sorry. I know... stupid, but true.

Etarena (talk)

Response from Mark

I think my adding "any java conditional statement" is confusing.. and maybe it shouldn't be so vague? Before the instruction steps is a blurb "a breakpoint that stops in the loop when the everythingIsOK flag is set to false" which is the hint to what the condition should be. But it's probably not worth making the user deduce the statement.

Or at the least, we could have an expand/hide box that provides the conditional statement

Hinerm (talk)

Need clearer explanation of when and why to use hit count

Hinerm (talk)

Exercise 4 - Ellen's Questions

That's right! I've made it to #4... but not without some more 'simple' questions...

I have NO idea what to do with :

ImageJ.app/ImageJ-linux64 --debugger=8000

huh?!

That's right. In this case... even the link did not help me.

Sorry!

I'll finish this exercise at a later point then...

Response from Mark

So this command is intended to be run from the command line, to launch ImageJ from a terminal so you can add the "debugger" configuration flag.

I wonder if there is a general scheme that could be used to quickly and unambiguously convey this kind of instruction.. like.. green = do this in eclipse, red = do this on the command line, etc...?

Hinerm (talk)

Also should add a link to Troubleshooting#Launching_ImageJ_from_the_console

Hinerm (talk)

Exercise 5 - Ellen's Questions

nope. got it.

but i didn't get the same 'bad' commit as was indicated... mine said something like 'Johannes wants more maths...

Mark's response

Note that this was the result of just **one step** of the bisect process. ;)

Hinerm (talk)

Exercise 6 Notes

If an individual doesn't know what a stack trace is they have no chance at completing this exercise. We need a link in the preamble to stack traces (and maybe even earlier, since we start talking about stack traces in exercise 1.. so maybe in Requirements?)

And again the goals could be clearer - that we are looking at situations where stack traces are not generated, so we have to take extra steps to collect this information.

Hinerm (talk)

Ellen's General point...

I like that you wrote a section for each exercise for the 'goals' ... can you do another thing at the end to summarize the main 'take-aways'... just to help keep the user in the right perspective of the exercise.

my last two cents - promise.

Etarena (talk)

Yes I think that's a good idea.. otherwise it may feel empty to complete an exercise, since you don't actually "solve" anything.

Hinerm (talk)

Add a Test section?

I was just thinking that it might be fun to add a companion test section, where the reader has to pick the appropriate debugging method for a variety of tasks? I don't know.. just a thought.

Hinerm (talk)