[Gambas-user] Profiler for Gambas projects

[Doriano Blengino]

Jussi Lahtinen ha scritto:
> It would still have performance impact,
> because interpreter would have to constantly check if profiler section
> of code is needed to execute.
> Compiler isn't used at runtime, so changes should be made to interpreter.
>   
I remember the old good days when turbo pascal came out. There was an 
IDE, with integrated compiler and debugger, like gambas. But there were 
also separate, command line, compiler and debugger (that debugger was a 
milestone. Never seen something better yet). Until here, this is similar 
to gambas.

Then, there was a command line profiler. The program to profile only 
needed to have debug information stored in the executable (just like 
gambas). There were two main ways to profile - statistical and another 
one, can't remember how it was named. The statistical method used a 
timer to interrupt the program, and counted the times the program 
counter was in a particular line of code at the time the timer 
interrupted the program. It does not really matter the frequency of the 
timer - what matters is to collect enough data. If a program takes only 
a few seconds to execute, then a high speed timer is needed. If the 
program is long (and at that time it was not uncommon for a program to 
take several hours to do the job), then a slower timer could be used. 
The result of profiling was a text file, which could be read by hand or 
used to have a graphical snapshot. The other method was to count the 
functions usage, func by func. I found the timer solution to be better, 
because normally I can guess how many times a routine gets called - no 
need to have something else to do that.

A gambas program can spend lots of its time in the idle loop and, in 
general, today's program can spend a lot of time in other duties (gui, 
disk, network and so on). So I think that some support for profiling 
could be added in the language, like the DEBUG instruction. For example 
a "PROFILE ON" or "PROFILE OFF". One could surround the whole program or 
just some piece of code by PROFILE ON and PROFILE OFF. When profiling is 
ON, the timer runs and collects data (which is not too much: a single 
integer for every line of source). This way a programmer can see, even 
in a single routine, which is the slowest instruction. By grouping data 
referring to a single SUB, a usage per subroutine can be derived.

The only thing I can add is that, by the time, this "profiling" loosed 
for me its importance - for several reasons, I think. Computers are much 
faster, compilers are more optimizing, analisys of the task and 
experience tell what to do - better than a profiler. This was clearly 
stated in the turbo profiler documentation: "the most important mean to 
write a fast program is to analyze which is the better algorithm, not to 
do tricks at the instructions level". But sometimes a profiler could be 
handy anyway.

Regards,

-- 
Doriano Blengino

"Listen twice before you speak.
This is why we have two ears, but only one mouth."