On Feb 3, 2009, at 8:43 AM, Dieter Oberkofler wrote: Still stuck with Saturn:
1) After initializing the application with initSaturn(""), it seems as if the profiling would already have started and within a few seconds around 500MB of data is collected.
If you use -pg, the moninit() method in libSaturn calls initSaturn() and startSaturn(). That means that Saturn will start tracing as soon as the bundle is loaded.
If you use -finstrument-functions, any function not decorated with "__attribute__((__no_instrument_function__))" will call into Saturn to record data. If that happens before a call to initSaturn() is made, initSaturn() and startSaturn() are called for you. If you decorate your bundle's initializer method with that, then it won't accidentally start Saturn automatically. 2) When trying to immediate stop profiling (I immediate call stopSaturn() the performance slows down to a point that it takes hours just to startup the app and the icon of the bundle starts to flicker.
This appears to be a bug. It looks like we do a bit of work on every function entry/exit even after stopSaturn() is called. This has a significant performance penalty and can cause the behavior you describe. If you decorate your bundle's initializer as described above, you will avoid this, but it may also keep recording data even when you don't want it to. 3) After some time a second folder/file (Saturn_profile_ljs-bin.001) is opened in the resources folder of the bundle next the Saturn_profile_ljs-bin.000 file that has been created immediate after starting the application in the root directory.
Each thread generates a separate data file. A new data file should also be generated for each start/stop pair.
I'm sure that a lot of people use Saturn and I'm just using it wrongly but some help would really be appreciated...
I'm not sure that anyone has tried to use Saturn in this way for quite a while. Most of our users use Shark to track down their performance issues. The data generated statistically is sufficient for tracking down methods that are hogging CPU time and the overhead is considerably lower.
Thank you, Dieter
On 29.01.2009, at 21:53, Rick Altherr wrote: On Jan 29, 2009, at 12:20 PM, Dieter Oberkofler wrote:
On 29.01.2009, at 21:17, Rick Altherr wrote:
On Jan 29, 2009, at 12:11 PM, Dieter Oberkofler wrote:
On 29.01.2009, at 21:04, Rick Altherr wrote:
On Jan 29, 2009, at 11:38 AM, Dieter Oberkofler wrote:
On 26.01.2009, at 17:58, Rick Altherr wrote:
On Jan 25, 2009, at 8:56 AM, Dieter Oberkofler wrote:
I have been trying to profile a i386 application and ended up in using Saturn as "the" only traditional (each function is actually reported) profiler according to the documentation.
After quite a few hours of recompiling, linking and guessing (it seems as if when running an application bundle in Saturn, the LSEnvironment is not evaluated) I finally have a fully instrumented application that can be executed in Saturn. This is what I did and I after my run, I wanted to load the generated Saturn data file and end up with the following error message: "The document "..." could not be opened. The file is to large". Checking the file shows that the fine is less then 2GB. A few questions that might help:
1) Is Saturn the proper tool to do some simple function profiling?
That all depends on what type of "simple function profiling" you want to do. Saturn is an exact function tracer meaning it has high overheard and knows the precise duration of every function call on every thread. It requires recompilation of your program and will cause your program to run at less than half its non-instrumented speed.
If you don't need to know precise information, you want to use Shark's Time Profile. It provides a statistical sampling of your programs execution. It can't tell you the amount of execution time for every function in your program or how often it is called, but it can tell you what portions of your program are taking the most execution time. It has very low overhead (less than 1% typically) and requires no modifications to your program.
I had a look at Shark but this would not help. I need am exact timing of each function and this seems only to be possible with Saturn.
Is there a specific reason you need exact function timing of _every_ function in a given code path? Most of the time you don't need that and can answer questions related to performance by a combination statistical sampling and tracing specific functions.
No, I would only need to trace a a range of function but this seems not be possible as a restriction with the frond-end. Should it be?
This is not available in the front-end as you need to place the start/stopSaturn() calls in your application.
I have now tried to use the API (initSaturn, startSaturn, stopSaturn) but got stuck as well:
How can I prevent the Saturn front-end to start profiling by default and only begin when I use startSaturn?
Don't use the front-end to launch the app. If you are using start/stopSaturn(), you can just run the instrumented program normally and it will generate the Saturn profile file.
Can I also run a bundle app?
libSaturn can be used by any executable as long as initSaturn is called first, and start/stopSaturn() are called in pairs.
Does initSaturn automatically start profiling?
It shouldn't, but I haven't verified that recently.
Can I start the bundle or do I have to start the binary within the bundle?
If you are putting the instrumentation in a bundle loaded by a host application (i.e. a plugin), then you run the host application and have it load your plugin just like a normal usage would.
Would I get an error if start/stop is not called in pairs?
A start without matching stop will just cause the sampling to run until the process terminates. A stop without a matching start should return an error.
--
Rick Altherr
Architecture and Performance Group
email@hidden
-- Rick Altherr Architecture and Performance Group email@hidden
-- Rick Altherr Architecture and Performance Group
|