[DGD] change in tick accounting

[bart at wotf.org]

On Sun, 24 Jun 2018 22:12:03 +0200, Felix A. Croes wrote

> > The only thing it may impact is profiling via eval cost, since 2 chunks of
code that don’t loop will now return the same values, even if one is quite a
bit longer.  Unless you added in an estimate, like the number of instructions
times a constant, perhaps?
> 
> Many kfuns have their own tick cost.  Even operations like 
> assignment and array/mapping indexing have a cost.  If there are no 
> loops the cost will now be lower; for tight loops, it could actually 
> be higher than before. As an approximation of execution time it is 
> less accurate, but only a little.
> 
> JIT-compiled code will perform the same operations and call the same
> kfuns, so the tick cost can be identical even though the execution time
> will be much lower.

That will have some interesting effects for some of my code, which does a lot
of splitting long running jobs into small chunks based on how many ticks are
used, and processes those small chunks with a call_out 'chain'. The purpose of
that is of course to ensure the system keeps responding to users while such a
job is running. From what you write I'll have to do some tuning to make such
jobs benefit from the JIT (as in, finish in less time while keeping the same
level of responsiveness).

Very interesting indeed. 

Is there a way for LPC code to determine if it is JIT compiled?

Bart.
--
https://www.bartsplace.net/
https://wotf.org/
https://www.flickr.com/photos/mrobjective/