[fpc-devel] [patch] pscanner: differentiate between EOL & Tab characters from general Whitespace

Graeme Geldenhuys graemeg.lists at gmail.com
Sun Aug 22 22:35:34 CEST 2010

On 22 August 2010 20:50, Dimitri Smits wrote:
> Anyway, if so, would this "profiling" stuff be optional, on/off all or on/off for a specific method/class/unit/package/program?

fpprofiler (which I now switched to instead of my own) is optional.
Profiling is applied per unit, and then "attaches" to every
procedure/function or method in that unit. fpprofiler can be told to
ignore certain units. How it currently works, is that you pass the
exact same compiler parameters to the profiler, as you would to
compile your project. It inserts the profiling code, compilers your
project with the profiling code, then reverts all profiling changes.
You end up with your "normal" code, but with a "fat" executable which
does profile logging for you.

Reporting wise, it does timing, call count and generates a call graph.
Output formats are Plain Text, LaTeX and PNG images for the call

What I like is that it is really easy to get started, and the
profiling information is nice and easy to understand and interpret.
Valgrind, callgrind, cachegrind, coffee-grinder etc... just seems very
complex to interpret. This will scare of any developer new to

Another BIG plus point for fpprofiler, is that it only requires FPC -
no other dependency. Something I always like - low dependencies! :)

I'm planning on integrating fpprofiler (or a similar profiler) into
fpGUI IDE (my sideline project), so you can enable it by a toggling a
checkbox (just like you currently can for Valgrind or Gprof via a
command line parameter). What I want to add extra into fpGUI IDE, is
more visual screen that interpret the profiling data.

Anyway, I'm getting way off-topic here... I'll wait an see what
Michael says regarding my last email and the new patch to fix the
pparser unit.

  - Graeme -

fpGUI - a cross-platform Free Pascal GUI toolkit

More information about the fpc-devel mailing list