On Mon, 21 Mar 2016, Sven Schreiber wrote:
Am 20.03.2016 um 22:40 schrieb Allin Cottrell:
> scratch each time it comes up for execution. (Note the implication for
> writers of hansl scripts: avoid string substitution if you want your
> code to run as fast as possible.)
Not widely known I'd bet...
Yes, we need to make that clear.
> I'm not dismissing Jack's suggestion. If a writer of
hansl marked a loop
> as "hi-perf" that could be understood as (say) committing the user NOT
> to use string-substitution, "delete" or "rename" within the loop,
so if
> any of these things appeared we could immediately flag an error. I'm
> just not sure that this is the best way to proceed, IF we're able
> reliably to work around the potentially threatening features.
Well, the implicit communication about which things slow a script down would
be a plus.
BTW, what's the kind of speed-up one can expect from this loop
optimization? I know it depends on the contents and context, but if
I add a "high performance" option I would like to see _on average_
at least a 30% speedup (purely subjective). Otherwise it would feel
a bit like a lame joke over time.
I agree that could be an issue. The thing is that optimization of loop
performance has been an incremental process. Each "layer" has started
out as something experimental, but as we've tested and the code has
stabilized and been found to be safe we've then "baked it in."
(Cue a "Thank You" to those who have helped shake out bugs in the
latest round of optimization; at this point I believe we've reached a
stable point.)
I'm confident that if we now stripped out all our loop optimizations
it would make a big difference to speed on a wide variety of scripts.
However, I'm not confident there's a substantial speed difference at
the margin. (And stripping out all loop optimizations, if it were
feasible, would really be a matter of introducing a low-perf option!)
Allin