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." ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
