Forum > Other
Another profiler for FreePascal?
Eugene Loza:
Hi all!
Recently I've written a "very-simple" macro-based profiler for my game: https://github.com/eugeneloza/decoherence/blob/master/src/profiler.pas (FPC 3.1.1 required)
Usage example: https://github.com/eugeneloza/decoherence/blob/master/tests/profiler/ProfilerTest.pas
Example output: https://github.com/eugeneloza/decoherence/files/1502992/171125_profiler.txt
I wonder, is there any need in that sort of stuff?
I mean, at this point the profiler is heavily-dependent on other game files and Castle Game Engine and requires manual operation, but I could do some improvements to make it much more "universal" and create an automatic source parser and analysis modules to release it as a usable tool if anything like that might be useful to others...
P.S. And yes, don't blame me too much, I know my programming skills are far below average :-[
Graeme:
Why not simply use FPProfiler - which seem to work in a similar way, but automaticalyl injects the profiling code into your units and automatically removes them afterwards. At least, that is how I remember FPProfiler working some years back.
http://wiki.lazarus.freepascal.org/FPProfiler
The problem with such profiles though, is that they modify the source code to enable profiling, and thus also modify line number information. But indeed, they are much more lightweight than "real" profilers that monitor the debug information in your executables.
Eugene Loza:
I've tried LazProfiler and it couldn't instrument my code correctly (actually destroyed it, but luckily I had a backup) :) That's why I had to make my own implementation. Which can be made independent of EpicTimer and other thrid-party units (yes, now it depends on CGE and my external units, e.g. for timer implementation, but this is a weak dependency and can be easily avoided) and be more "fail-safe".
The largest problem is parser for such profilers, e.g. even JEDI and CodeTools fail at some valid FPC syntax (especially when it comes to compiler directives and, especially, macro). Basically, that's the problem actually nearly unsolvable, so finally we'll have just another "poor" profiler that has poor instrumentation support.
Graeme:
--- Quote from: Eugene Loza on December 10, 2017, 10:49:21 am ---I've tried LazProfiler and it couldn't instrument my code correctly (actually destroyed it, but luckily I had a backup) :)
--- End quote ---
That is worrying - don't you use SubVersion or Git to version control your software?? I highly suggest you start.
--- Quote ---yes, now it depends on CGE and my external units, e.g. for timer implementation,
--- End quote ---
So the point is moot - both have dependencies.
--- Quote ---The largest problem is parser for such profilers, e.g. even JEDI and CodeTools fail at some valid FPC syntax
--- End quote ---
You don't need a parser for that. Granted I don't know LazProfiler (is that a renamed FPProfiler?). Also I haven't followed FPProfiler in recent years. The last time I worked on FPProfile was some 7 years ago - my code is still available [https://github.com/graemeg/fpprofiler].
If you look at my code, you will see, no parser is required. You simply use a tokenizer to find begin..end pairs of functions or procedures and inject your profiling code after/before those tokens. It doesn't need to know anything about the syntax or logic of the language.
Like I said, maybe the later "official" FPProfiler now uses a Object Pascal parser, but the FPProfiler in my code repository (from 7 years ago) did not need that.
Thaddy:
Has there been done any work on Eric's Sampling profiler? I happen to like that a lot for my Delphi code and it does not rely on instrumentation.
https://www.delphitools.info/samplingprofiler/
Navigation
[0] Message Index
[#] Next page