blog: Overlooked Essentials for Optimizing Code

[Daniel Gibson]

Nick Sabalausky schrieb:
> "Daniel Gibson" <metalcaedes at gmail.com> wrote in message 
> news:i6fa0l$j7b$2 at digitalmars.com...
>> Jesse Phillips schrieb:
>>
>>> Is there information on what the output of trace.log and trace.def mean? 
>>> And I guess I can run the demaingler against  this output, any tools 
>>> already handle this?
>> Documentation of the profilers output would be helpful indeed.
>>
>> That last table in trace.log is self-documenting and already contains the 
>> most important information: what function is executed how often, how much 
>> time does that take and how much of that time is used within that function 
>> itself ("Func Time") opposed to the time taken by functions called from 
>> that function ("Tree Time" - "Func Time")
>>
>> Don't know about the rest of trace.log though - maybe it's "the fan in and 
>> fan out, which is essentially the call graph. From it, you can tell why 
>> and from where foo() is being called 1000 times when you only thought it 
>> should be called 3 times." (which a good profiler will tell you according 
>> to Walter on reddit[1])?
>>
>> Also: The output would be much more readable if it was demangled.
>>
>> A tool that parses trace.log and generates a nice (html?) representation 
>> of the data would be really cool :-)
>>
> 
> An interactively-inspectible one would be really great. (More work though, 
> obviously.)
> 

Via integration into an IDE maybe? That'd be cool - run the profiler and 
afterwards click on the function names in the representation to get to 
the functions and to the points they're called (from the fan in/out 
data) - maybe with annotations in/next to the source or something like that.

If any IDE dev reads this: Proper integration of the profiler would be a 
killer feature :-)
(But honestly I'd be thankful for any IDE with proper auto completion 
and maybe refactoring that works on Linux - the eclipse plugins don't 
seem to work for me, codeblocks neither..)