when performance profiling with JProbe you can view the time spent on each line of specific methods.
Is there an equivalent feature in JProfiler?
There is no source code view where you could see each line with an associated time measurement. However, JProfiler can record line numbers, see
https://stackoverflow.com/a/9290227/936832
Note that in that case, the displayed line numbers in the call tree refer to the parent nodes.
Related
My Labview Program works like a charm, until I look at the Block Diagram. No changes are made. I do not Save. Just Ctrl+E and then Ctrl+R.
Now it does not work properly. Only a Restart of Labview fixes the problem.
My Program controls two Scanner arrays for Laser Cutting simultaneously. To force parallel working, I use the Error handler and loops that wait for a signal from the Scanner. But suddenly some loops run more often than they should.
What does majorly happen in Labview when I open the Block diagram that messes with my code?
Edit:
Its hard to tell what is happening without violating my non-disclosure agreement.
I'm controlling two independent mirror-Arrays for Laser Cutting. While one is running one Cutting-Job, the other is supposed to run the other Jobs. Just very fast. When the first is finished they meet at the same position and run the same geometry at the same slow speed. The jobs are provided as *.XML and stored as .net Objects. The device only runs the most recent job and overwrites it when getting a new one.
I can check if a job is still running. While this is true I run a while loop for the other jobs. Now this loop runs a few times too often and even ignores WAIT-blocks to a degree. Also it skips the part where it reads the XML job file, changes the speed part back to fast again and saves it. It only runs one time fast.
#Joe: No it does not. It only runs once well. afterwards it does not.
Youtube links
The way it is supposed to move
The wrong way
There is exactly one thing I can think of that changes solely by opening the block diagram.
When the block diagram opens, any commented-out or unreachable-code-compiler-eliminated sections of code will load their subVIs. If one of those commented out sections of code were somehow interfere with your running code, you might have an issue.
There are only two ways I know of for that to interfere... both of them are fairly improbable.
a) You have some sort of "check for all VIs in memory" or "check for all types in memory" that you're using as a plug-in system. When the commented-out sections load, that would change the VIs in memory. Such systems are not uncommon when parsing XML, so maybe.
b) You are using Run VI method for some dynamically invoked VI to execute as a top-level VI, but by loading the diagram, it discovers that it is a subVI of your current program. A VI cannot simultaneously be top-level and a subVI, so the call to Run VI returns an error.
That's it. I can't think of anything else. Both ideas seem unlikely, but given your claim and a lack of a block diagram, I figured I'd post it as a hypothesis.
In the improbable case someone has a similar problem. The problem was a xml file that was read during run time. Sometimes multiple instances tried to access it and this produced the error.
Quick point to check: are Debug and "retain data in wires" disabled? While it may not change the computations, but it may certainly change the timing of very tight loops, and that was one of the unexpected program behaviors, OP was referring to.
I have a drawing application that I'm working on for the iPad. I'm trying to speed up my drawing, so I was running some tests with the time profiler instrument. However, I'm either doing something wrong or the time profiler just isn't going to be helpful in this situation.
What I'm looking for is basically a line by line execution time for the code that is doing my drawing. What I got instead is below. Basically, the time profiler says "you're spending a lot of time drawing". My response is "Oh rly!?". Am I using the profiler correctly, or is there a way to get it to display line by line execution times (which would be much more useful than the current output)?
Edit: Above, you can see more what I'm looking for. Line by line execution times. That is not MY code, just an example of how I want/expect the time profiler to work.
Edit2: Can you only see method by method execution times when running on the simulator? I just tried profiling on the simulator and the output is exactly what I would expect. However, I was really hoping for more accurate profiling using the device :(
The time profiling tool does not seem to behave the same on the device as in the simulator. The simulator version allows me to see line by line execution times, where as when profiling on the device, I only get output above, which is far less useful.
I believe, you cannot achieve this with time profiler, as it gathers lots of samples and unifies them to show, where you spend time the most.
You might have a solution for this task using some "raw" dtrace scripting. Or, you can write a sampling code based around mach_absolute_time (this QA might be useful to convert the values to more meaningful data later on).
To get the line by line execution times you want, you must double-click on a function that you wrote in the call tree. In your screenshot you double-clicked a UIView method, which Apple wrote. You're getting disassembly because it's Apple's code, not yours.
If you want to focus on your code in the call tree, select the Hide System Libraries checkbox, which is just above the Show Obj-C Only checkbox you selected in your screenshot. Hiding system libraries makes it easier to find your code in the call tree, which will help you get to the line by line execution times.
I need to prove that a VB.NET program that I wrote was written at a particular time.
(the reason is an academic integrity investigation where someone copied my code).
I have all the code on my disk including the debug and release folders, with my username in the build paths.
Are their addition things I could do, such as looking in the binaries?
If you use IL Disassembler to open the EXE/DLL, then select menu option View>Header, there is a field called "Time-date stamp" in the COFF/PE header. It's in binary format, and according to MSDN it is:
The low 32 bits of the time stamp of the image. This represents the date and time the image was created by the linker. The value is represented in the number of seconds elapsed since midnight (00:00:00), January 1, 1970, Universal Coordinated Time, according to the system clock.
First thing you should do it copy all of the data as it stands to another device - making sure you preserve all date times. Do not open or edit any of the files.
Each file will have three timestamps, when it was created, when it was last modified etc. These can be found using DIR /T
/T Controls which time field displayed or used for sorting
timefield C Creation
A Last Access
W Last Written
Get a listing of the directory like this:
DIR myrootdir /s /ah /as /tc > fileslist.txt
This will dump out all the files with creation times to a file called fileslist.txt
Also as #EricJ says : offer your disk as evidence - but like I said make a copy first. It would be best to make an image copy (windows backup) to an another drive first.
The investigators are going about this all the wrong way.
Any timestamp data can be faked, so the best way would be for them to sit down and ask detailed questions about how the code works, to both parties seperately.
Or to ask both parties to complete a small test project, again seperately - under exam conditions.
The one that copied the work wont understand what they copied most likely, and wont be able to reproduce something based on similar concepts.
The one who did write it - well unless they cheated to, they will understand it all in depth.
Sometimes when looking at someone else's large Objective-C program, it is hard to know where to begin.
In such situations, I think it would be helpful to log every call to every non-Apple method.
Is there a way to do that? Basically, make one change in some central place, and log every method that is called. Preferably limited to non-Apple methods.
You can set the environment variable NSObjCMessageLoggingEnabled to YES. This will write a log of all message sends in the folder /tmp/msgSends-xxx.
You could add a symbolic breakpoint to objc_msgSend(), and have it log the second parameter without stopping.
How to do it for your own methods only though is a toucher task. Maybe if you could inspect the class name being called and do some magic to have a conditional breakpoint for only calls where the class' prefix matches your own?
I don't think logging every single call is practical enough to be useful, but here's a suggestion in that direction.
On a side note, if it's a large program, it better have some kind of documentation or an intro comment for people to get started with the code.
In any case, every Cocoa application has an applicationDidFinishLaunching... method. It's a good place to start from. Some apps also have their principal (or 'main window') class defined in the Info.plist file. Both these things might give you a hint as to what classes (specifically, view controllers) are the most prominent ones and what methods are likely to have long stack-traces while the program is running. Like a game-loop in a game engine, or some other frequently called method. By placing a breakpoint inside such a method and looking at the stack-trace in the debugger, you can get a general idea of what's going on.
If it's a UI-heavy app, looking at its NIB files and classes used in them may also help identify parts of app's functionality you might be looking for.
Another option is to fire up the Time Profiler instrument and check both Hide missing symbols and Hide system libraries checkboxes. This will give you not only a bird's eye view on the methods being called inside the program, but also will pin-point the most often called ones.
By interacting with your program with the Time Profiler recording on, you could also identify different parts of the program's functionality and correlate them with your actions pretty easily.
Instruments allows you to build your own "instruments", which are really just DTrace scripts in disguise. Use the menu option Instrument >> Build New Instrument and select options like which library you'd like to trace, what you'd like to record when you hit particular functions, etc. Go wild!
That's an interesting question. The answer would be more interesting if the solution supported multiple execution threads and there were some sort of call timeline that could report the activity over time (maybe especially with user events plotted in somehow).
I usually fire up the debugger, set a breakpoint at the main entry point (e.g. - applicationDidFinishLaunching:withOptions:) and walk it in the debugger.
On OSX, there are also some command-line tools (e.g. sample and heap) that can provide some insight.
It seems like some kind of integration with instruments could be really cool, but I am not aware of something that does exactly what you're wanting (and I want it now too after thinking about it).
If one were to log a thread number, and call address, and some frame details, it seems like the pieces would be there to plot the call timeline. The logic for figuring out the appropriate library (Apple-provided or third party) should exist in Apple's symbolicatecrash script.
I wondered if anybody could help me with a technique to address the following problem in Smalltalk. Specifically Cincoms Visualworks.
I would like to code a simple GUI that has three fields and processes them as follows:
The first field inputs a number (5 say).
The second field simply displays twice the first field (so it displays 10 in this example)
Now, the interesting bit... the third field displays a value from a completely different class (let's call it class X). However, the value must be displayed on the GUI whenever that value in the class X changes - it mustn't wait for a key press from an update button. The value in class X could be sourced from (say) the workspace.
I though I could do this via aspect adaptors but I can’t seem to get the 'third field value' to update asynchronously.
Any techniques, hints or tips will be most warmly welcomed - (especially code snippets!!).
Thanks
Kevin
I've sorted this myself. After trying the dependency mechanism (works fine - but simply not needed), looking at announcements (thanks James at Cincom - personal communication) I found that all I needed to do was to simply create a method and send it a message with a parameter (my value) that method then simply updated the value holder (i.e. the aspect of the GUI field) with the "value:" message. The more I look into Smalltalk the more I like it!