This came up in a round of log spelunking where our use of XCALL FILL and TRIM flooded the ashlog when the XCALL trace was enabled. I asked if the compiler could convert these to the internal equivalents, as you mentioned they would perform better.

Just making this post to see if this idea has any legs.

This has been near the top of my list since the subject came up awhile back. I'm generally in favor of it, but am have some concerns still percolating in the back of my mind, such as:

• The performance benefit is small (but possibly appreciable for routines like STRIP, FILL or TRIM that are called zillions of times.) In fact, it's next to impossible to accurately measure the advantages other than with aggregate tests, i.e. total time for a million iterations.
• There is always a non-zero risk of some slight behavior change, so it needs a lot of testing. (Although arguably, TRIM, STRIP and FILL are pretty straightforward.) In fact, in all of these cases, we'd end up executing the same code; the difference would be in the compilation, i.e. spitting out tokens for internal function calls rather than XCALLs.
• It's not clear whether adding another compiler switch (to simplify side-by-side testing) would be worth it. One argument for making the optimizations optional is that the optimized RUN might require a newer runtime version than the non-optimized version. (The TRIM$ function, for example, was only introduced in 6.5.1713, whereas XCALL TRIM has been around for decades.)
• If we do add a compiler switch (/opt for optimization?, or /o1 for optimization level 1?), that might open the Golden Door (or Pandora's box?) to further optimizations.

Not sure I understand the issue...

It's just about performance optimization. XCALLs are pretty efficient, but relative to internal functions they have a lot more overhead, first to locate the routine, then to set up the calling parameters, then to process the return parameters. In the case of a very simple routine, like TRIM or FILL, that could result in a 10X difference in the number of low level instructions executed. (Still, that may only be a difference of a few nanoseconds, unless the routine is called a lot, as could be the case with routines like TRIM or STRIP.) And then there is also the issue of them cluttering up the log if you activate the XCALL TRACE. So the idea was to have the compiler optimize them by compiling them not as XCALLs but as internal functions.

More generally, there may be other statement constructs that could be optimized, sometimes dramatically so. Herman, for example, once discovered that a loop appending characters to a dynamic string had an exponential decay in performance. That led to a much better implementation that's now basically linear, orders of magnitude faster as the target string gets longer.

But these kinds of situations need to be discovered before they can be optimized. I had hopes that the new RUNPROF utility might be useful in that quest, but it struggles with a couple of related obstacles:

• Most individual routines, like TRIM, are so quick that they don't even measure on the CPU clock. So you have to call them a lot of times before the total time starts to become noticeable.
• Programs with that a high degree of iteration of function calls generate such massive logs that they become difficult to manage. I'm still working on ways to deal with that.

Of course, with today's processors, most applications are more likely to be bound by something other than the CPU. But there's also a tendency to use more and more levels of nested routines as programs become more sophisticated, flexible, generalized, etc. So it's kind of a cat and mouse issue, and therefore worth periodic review and refinement.

My reason for thinking about this was in the context of eliminating these from the ashlog with XCALL trace.

We could fairly easily find/replace these in our code, but another programmer is likely to add more later. Also, it's not the best time to do this find/replace work in the middle of debugging a problem you just need to get to the bottom of.

Or add a list of XCALL to get ignored in the trace

Thanks for the clarify!

After letting this idea run around unsupervised for awhile, and even implementing the compiler conversion of XCALL TRIM,A$ to A$ = TRIM(A$), and XCALL FILL,A$,B$ to A$ = FILL(B$,sizeof(A$)), I think maybe Jorge's idea is best -- a new MIAME.INI directive NOTRACE= for selectively disabling traces that have been more generally enabled. So the combination of...
would enable traces for xcalls generally but skip TRIM and FILL.

Initially this would only apply to XCALLs, but opens up the potential to disable other kinds of traces that may be too verbose (like XDEBUG or GUI).

My concerns about converting these or other XCALLs to internal functions are:

• There's no way for the compiler to know if you're planning to ALIAS them at runtime. (Converting them to functions would make them un-ALIAS-able.)
• It's difficult to be absolutely certain that the compiler conversion is going to resulting precisely the same runtime behavior in all cases.
• It's especially difficult to deal with optional parameters (which both TRIM and FILL) have.
• While the internal function versions were somewhat faster, it's not the dramatic, and it may be possible to get similar performance improvements just by optimizing the XCALL runtime wrapper, which would have more general benefit anyway.

So that's the current plan. I expect to release the update within the next 2-3 days (there are a few other minor issues to be resolved at the same time).

That makes sense.

Here's the update. See the release notes for details on the new NOTRACE directive ...

ash-7.0.1754.0-el7-upd.tz
ash70notes.txt