Following the guidelines in the Camel, online docs, and what I could grok of the source code, I kept coming up with seriously contrived uses. Okay, I did find a few uses that seemed to apply and didn't look so bad. So like any "optimization" scheme, I set up some benchmarks so that I could recommend it or at least further specify *exactly* where study benefits.
By the time that I had a broad list of examples where studywas beneficial, and a list where it didn't help (or even hurt) performance it would have taken several pages to explain *why* it works this way -- and along the way dancing around implementation details of the language that I really didn't care to explain. Very, very small changes in the input data would cause large swings in the benchmark timings. I didn't want a huge checklist of cases and exceptions with disclaimers making the whole thing moot anyway.
So I documented what I found (which is essentially what the Camel 3ed and the docs say) but with even broader warnings and more vigorous handwaving.
In reply to Re: Why study a SCALAR?
by clintp
in thread Why study SCALAR?
by mrbbking
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |