On 03/26/2013 12:22 AM, Vladimir Panteleev wrote:
> On Friday, 22 March 2013 at 22:39:56 UTC, Walter Bright wrote:
> A polling profiler would be more precise and efficient than an
> instrumenting profiler.

I don't see why we should switch the profiling method.
Using sampling profilers has a lot of benefits but also some drawbacks and there are already a lot of them out there, e.g. http://en.wikipedia.org/wiki/Profiling_(computer_programming)#Statistical_profilers.
On unix you can use gprof which is as simple as passing "-pg" to the gcc link command and calling gprof on the output data.

On 03/25/2013 11:37 PM, Sean Kelly wrote:
> On Mar 22, 2013, at 3:39 PM, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> http://d.puremagic.com/issues/show_bug.cgi?id=9787
>>
>> This can be a fun little project, with a nice payoff. Any takers?
>
> Bonus points if the code is made multithread capable.  When I was thinking about this before, the correct approach seemed to be tracking profile data on a per-thread basis and then merging results into final on thread termination.
>
Good to know and sounds fairly trivial.

On Tuesday, 26 March 2013 at 16:33:19 UTC, Martin Nowak wrote:
> On 03/26/2013 12:22 AM, Vladimir Panteleev wrote:
>> On Friday, 22 March 2013 at 22:39:56 UTC, Walter Bright wrote:
>> A polling profiler would be more precise and efficient than an
>> instrumenting profiler.
>
> I don't see why we should switch the profiling method.

I'm not saying we should. Just letting D users know that other solutions exist, which would work better in some situations.

On Tuesday, 26 March 2013 at 07:45:34 UTC, Walter Bright wrote:
> On 3/25/2013 10:16 PM, deadalnix wrote:
>> You can still stop the thread, gather the data you are interested in, and doing
>> the whole process while resuming the application, which leverage concurrency.
>
> The obvious difficulty with that is when the app is posting data to the profiling thread faster than the latter can process it.

That's not how polling profilers work.

Polling profilers do not run alien code in the programs' thread. Thus, the program thread is not posting anything to the profiling thread.

I'm repeating myself, but: they work by having the profiler thread/process periodically pause the program thread, record its state, resume it, then analyze/store the collected data, and sleep a bit before taking another sample.

Even when the overhead of a polling profiler is higher, it has the qualifying difference in that the performance overhead does not skew the execution times of particular parts of a program as much as an instrumenting profiler. That is, while an instrumenting profiler makes some parts of the program much slower than others, a polling profiler should make the whole program about equally slower.

On 3/26/2013 4:52 PM, Vladimir Panteleev wrote:
> Even when the overhead of a polling profiler is higher, it has the qualifying
> difference in that the performance overhead does not skew the execution times of
> particular parts of a program as much as an instrumenting profiler. That is,
> while an instrumenting profiler makes some parts of the program much slower than
> others, a polling profiler should make the whole program about equally slower.

I've done a lot of very successful optimization jobs using -profile. Sure, it isn't terribly accurate, but it's plenty accurate enough where it matters.

On Tuesday, March 26, 2013 17:17:51 Walter Bright wrote:
> I've done a lot of very successful optimization jobs using -profile. Sure, it isn't terribly accurate, but it's plenty accurate enough where it matters.

I'd say that for the most part, our approach to stuff like -profile or unit testing is to provide a simple-to-use feature that solves the problem 90% of the time while leaving more powerful (and therefore more complicated) stuff to 3rd party solutions. That way, we have a tool that everyone can use effectively even if it doesn't have all of the bells and whistles, and those that really care about the bells and whistles can do what they normally would have done anyway if we didn't provide a solution (i.e. use or write a 3rd party solution).

- Jonathan M Davis

On 3/26/2013 6:30 PM, Jonathan M Davis wrote:
> On Tuesday, March 26, 2013 17:17:51 Walter Bright wrote:
>> I've done a lot of very successful optimization jobs using -profile. Sure,
>> it isn't terribly accurate, but it's plenty accurate enough where it
>> matters.
>
> I'd say that for the most part, our approach to stuff like -profile or unit
> testing is to provide a simple-to-use feature that solves the problem 90% of
> the time while leaving more powerful (and therefore more complicated) stuff to
> 3rd party solutions. That way, we have a tool that everyone can use effectively
> even if it doesn't have all of the bells and whistles, and those that really
> care about the bells and whistles can do what they normally would have done
> anyway if we didn't provide a solution (i.e. use or write a 3rd party
> solution).

Yup. My experience with such things, including profiling, coverage testing, unit testing, documentation, lambdas, etc., is that if it ain't easy, it just ain't happening.

I remember in the 80's getting a profiler, and with it came a manual that was an inch thick. It never got used.