Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

modifications on the profiler plugin (cosmethical)

<< < (2/3) > >>

frithjofh:
By the way, I think there is a crash condition in the profilers configuration dialog. (I don't think that it was introduced by me though, as I didn't touch that functionality) Checking the option "file info" lets c::b crash on execution of profiler plugin. I attached the crash report.

So I checked the other configuration options too.

- "Brief" doesn't seem to change anything in the output
- "File info" crashes c::b
- "Annotated source" I didn't try
- "No static" didn't change the output
- "Minimum count" doesn't seem to work as aspected, the output is not changed and the number is only settable up to 99
- "Sum" took a long time showing a busy cursor but at the end the output dialog doesn't even show. I think I simply don't understand this option

Is all of this work in progress or am I getting something wrong?

Regards

PS: it seems strange, that the file format of the crash report is not an allowed file type for attachment ...

[attachment deleted by admin]

MortenMacFly:

--- Quote from: nausea on October 08, 2009, 12:27:07 pm ---Is all of this work in progress or am I getting something wrong?

--- End quote ---
The crashes all appear here:
cbprofilerexec.cpp:265 with the following code:

--- Code: ---if (!(count%STEP))
--- End code ---
...with STEP being calculated like:

--- Code: ---const size_t STEP = maxcount/RATIO;
--- End code ---
As you see: This can go zero, which is no good and surely will result in a crash (division by zero).

MortenMacFly:

--- Quote from: nausea on October 08, 2009, 12:27:07 pm ---- "Brief" doesn't seem to change anything in the output
- "File info" crashes c::b
- "Annotated source" I didn't try
- "No static" didn't change the output
- "Minimum count" doesn't seem to work as aspected, the output is not changed and the number is only settable up to 99
- "Sum" took a long time showing a busy cursor but at the end the output dialog doesn't even show. I think I simply don't understand this option

--- End quote ---
For these inspect the documentation of gprof, e.g. here:
http://unixhelp.ed.ac.uk/CGI/man-cgi?gprof

These parameters depend on the executable you are profiling and may have no effect, indeed.

MortenMacFly:

--- Quote from: MortenMacFly on October 08, 2009, 03:23:53 pm ---As you see: This can go zero, which is no good and surely will result in a crash (division by zero).

--- End quote ---
OK... some more tests... the RATIO was not a good idea at all I guess. Why did you implement this? If there is no good reason I'd prefer the way it was before.

frithjofh:
Hi, thanks for the replies,

well, good catch, I feel a little bit dump having commite exactly that stupid error. The division by 0. Almost the first thing you read in every text about programming errors ...

The reason why I wanted to chang this is that the update of the wxProgressDialog, as it is now, at least on my project with has about 30 files (so it is rather small), slows down the whole thing. If I comment out all the updating of that wxProgressDialog, the plugin parses my project in about one second. Whith the wxProgressDialog as is it takes about 10 seconds. I wanted to speed this dialog up having it been called less and updating each time a greater chunk of the gauge, not having it update by one step for every line of data that gets parsed ...

The idea of using all that (not very bright) division by zero code was to update the gauge in equal steps in relation to the number of lines that get parsed, that is to say, no matter what the size of the wxArrayString containing the data it will always update the wxProgressDialog in a fixed number of steps (like 30 updates or 20, or what so ever ) which would be calculated by the part


--- Code: ---const size_t STEP = maxcount/RATIO;
--- End code ---

I guess I just realized that the modulo is still a division. But I still think that updating the gauge for every line parsed is not a good idea, serious ...

That -m option : is it right that it refers to the non standard c and c++ extension of basic-blocks ?? I'm not sure, but I seem to remember that gcc does not produce any basic-block profiling information when profiling ... but I'm surly wrong there, and besides I don't know about other compilers.

Well, these were my motives. Thanks for the punch on the nose  :) I will think it over and try something better. What do you say of the rest of my changes ?

Regards

nausea

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version