Big analysis files / Clear Case

[Michael_Wieczorek]

Hello I'm a beginner of using the Intel inspector, so I've got some questions in different matter. I hope you have got any answers for me… :-) Do you know anything about the directory structure and the files which will be generated from the inspector while a analysis? It's among others due to the idea to use CVS, ClearCase, … to manage these files. The problem is that some files in same cases are very, very large. For example: /data.0 *.pdr --> 198MB *.db3 --> 130MB *.db3.337 --> 130MB *.pdr_out --> 861MB Which files contain which information? Are there temporary files, which I need not to checkin (esp. in data.0) ../source_cache/*.* are temp-files, so far as I know Do you use ClearCase, CVS, … or something like that for manage your inspector files? Thank you very much! Best regards, Michael

[Michael_Wieczorek]

sorry for the terrible layout 8-)

Hello!

I'm a beginner of using the Intel inspector, so I've got some questions in different matter. I hope you have got any answers for me…

Do you know anything about the directory structure and the files which will be generated from the inspector?

It's among others due to the idea to use CVS, ClearCase, … to manage these files. The problem is that some files in same cases are very, very large. For example:

/data.0

•   *.pdr --> 198MB
•   *.db3 --> 130MB
•   *.db3.337 --> 130MB
•   *.pdr_out --> 861MB

Which files contain which information? Are there temporary files, which I need not to checkin (esp. in data.0) like ../source_cache/*.*? Do you use ClearCase, CVS, … for manage your inspector files?

Thank you very much!

With best regards,

Michael

[Holly_W_Intel]

I'm not clear on why you are wanting to put the Inspector results files in your source control system. Understanding that would give me a better sense of what you need to maintain in order to effectively use the data in the future.

The data.0 directory contains both raw data as it came from the collector and data that has been processed to deal with any suppressions you may have applied or states that you may be propagating from run to run. In general, if you are going to be re-running Inspector, for example for QA purposes, you will want to have the most recent results (including the data.0 directory) for each analysis type and dataset that you are running, and any significant baseline you are tracking from, but you do not need earlier results files.

If you give me more information about why you are storing the files, I will be better able to explain the particular situation.

thanks

Holly

[Michael_Wieczorek]

Thank you for you answer, Holly! The reason for putting the Inspector results in our source control system was to have a central location so all developers have a simple access to the results (incl. backup), without a risk of deleting the files. But you are absolutely right: version control is not necessary, not really. But: Do you have a workflow considering the following simplified steps (1) analyse with Inspector (2) review the results --> serious problems? --> priorities (3) (bug) fixing!!! (4) change the state of a problems e.g. "fixed" ... If you have e.g. 20 developers and more do you track the errors directly in the Inspector project - then I could need a version control - or do you have an extra issue list, like excel? What is your hint? Are there best practices? That would be great... :-) Ok, back to the point of the big result files. Is it normal, that the files are become so big? What could be the reason for that? Strange to say, the other results are smaller although it was the same szenario and the found problems have the same count. Thx! Michael

[SergeyKostrov]

>>...If you have e.g. 20 developers and more do you track the errors directly in the Inspector project - then I could need a version >>control - or do you have an extra issue list, like excel? What is your hint? Are there best practices?.. Every software company has its own way of dealing with performance reports, etc. Some solution could work for a Company A and it won't work for a Company B. I also dodn't understand why it has to be in some Version Control System. Since some developers could work on a very modified set of sources, and very different from original set of sources used by Inspector XE to build these reports, it makes sense for the developers to have their own local reports. This is some kind of integrity problem and the best solution is do your own analysis when you need on up-to-date set of sources checked-in at the moment.

[Holly_W_Intel]

Hi Michael, the answer to that is that you only have to keep the most recent results in order to have that information.

IXE keeps state information, and whenever you run a new analysis, the tool finds the most recent analysis of that type in this result and uses that to bring the state forward. For using the result across engineers, you can either store the most recent one that everyone is working on, or forward the results to everyone, either way you can take advantage of the merge states functionality to bring in the states (fixed/confirmed/regression) from all of the analysis into one result before you run again.

The new result uses the result directory from the previous, with everyone's states marked in it, and you have it all there.

If you look in the help files under _Investigating Results_, _Collaborating on Results_, you should find some very useful information on handling this case.

If you want to use a version control system to do this, I would recommend storing a limited number of past results, instead of part of the result files.

holly