text: updated copyright year after changing license notice
  \ get some data on potential (partial) inlining \. \ relies on some Gforth internals \ !! assumption: each file is included only once; otherwise you get \ the counts for just one of the instances of the file. This can be \ fixed by making sure that every source position occurs only once as \ a profile point. true constant count-calls? \ do some profiling of colon definitions etc. \ for true COUNT-CALLS?: \ What data do I need for evaluating the effectiveness of (partial) inlining? \ static and dynamic counts of everything: \ original BB length (histogram and average) \ BB length with partial inlining (histogram and average) \ since we cannot partially inline library calls, we use a parameter \ that represents the amount of partial inlining we can expect there. \ number of tail calls (original and after partial inlining) \ number of calls (original and after partial inlining) \ reason for BB end: call, return, execute, branch \ how many static calls are there to a word? How many of the dynamic \ calls call just a single word? \,? ! ; \ Various words trigger PROFILE-THIS. In order to avoid getting \ several calls to PROFILE-THIS from a compiling word (like ?EXIT), we \ just wait until the next word is parsed by the text interpreter (in \ compile state) and call PROFILE-THIS only once then. The whole \ BEFORE-WORD hooking etc. is there for this. \ The reason that we do this is because we use the source position for \ the profiling information, and there's only one source position for \ ?EXIT. If we used the threaded code position instead, we would see \ that ?EXIT compiles to several threaded-code words, and could use \ different profile points for them. However, usually dealing with \ the source is more practical. \ Another benefit is that we can ask for profiling anywhere in a \ control-flow word (even before it compiles its own stuff). \ Potential problem: Consider "COMPILING ] [" where COMPILING compiles \ a whole colon definition (and triggers our profiler), but during the \ compilation of the colon definition there is no parsing. Afterwards \ you get interpret state at first (no profiling, either), but after \ the "]" you get parsing in compile state, and PROFILE-THIS gets \ called (and compiles code that is never executed). It would be \ better if we had a way of knowing whether we are in a colon def or \ not (and used that knowledge instead of STATE). Defer before-word-profile ( -- ) ' noop IS before-word-profile : before-word1 ( -- ) before-word-profile defers before-word ; ' before-word1 IS before-word : profile-this-compiling ( -- ) state @ if profile-this ['] noop IS before-word-profile endif ; : cock-profiler ( -- ) \ as in cock the gun - pull the trigger ['] profile-this-compiling IS before-word-profile [ count-calls? ] [if] \ we are at a non-colondef profile point last-colondef-profile @ profile-straight-line off [endif] ; : hook-profiling-into ( "name" -- ) \ make (deferred word) "name" call cock-profiler, too ' >body >r :noname POSTPONE cock-profiler r@ @ compile, \ old hook behaviour POSTPONE ; r> ! ; \ change hook behaviour :