I am all for an easy-to-understand performance model. But it is merely
one quality of many that we are optimizing for, and it is absolutely,
positively, *not* the high-order bit for how we expose the feature.
There will be room for outlining the tradeoffs, but there is not room
for "we can't allow case X strictly because it would be slower than case
Y." That's performance myopia, and even to the degree it would be
acceptable, it is surely premature. So let's move on.
On 11/2/2021 2:25 PM, Remi Forax wrote:
------------------------------------------------------------------------
*From: *"Brian Goetz" <brian.go...@oracle.com>
*To: *"John Rose" <john.r.r...@oracle.com>
*Cc: *"amber-spec-experts" <amber-spec-experts@openjdk.java.net>
*Sent: *Mardi 2 Novembre 2021 18:43:29
*Subject: *Translation musings (was: Are templated string embedded
expressions "method parameters" or "lambdas"?)
I think we need to redirect a bit.
I’m pointing out a different proposition: *If* you need
static validation of a string, *then* you need something
constant about the receiver. By constant I mean, very
specifically, “fixed no later than just before the first
execution of of the string template expression”. The
“something constant” might be the type (some subtype of a
known “ST-Handler”), or it might be a constant value (e.g., a
static final field value).
And I'm saying something different:
- We never *need* static validation of the string.
- We never *need* an indy-based, multi-step translation.
Both of these are nice to haves, not must-haves; the goal is to
extract these when we can have them, not to restrict the feature
so that we can't use the feature if we can't produce them.
We are in deep danger of way over-rotating towards the
translation. I would go as far as to say that if we always, now
and for the forever future, just translated with
"invokeinterface", it would *still* be a successful and popular
feature. Do we want to do better when we can? Of course. Are we
willing to restrict the feature to the cases where can do so?
Absolutely not.
It's really easy to get wrapped around the axle over cases like
String::format, and convince ourselves that this is the 99% use
case. But this represents only a slice (yes, an important slice)
of the benefits we get from this feature. In many cases, the work
we'll do to translate the template (e.g., a CLASS."public class
Foo { ... }" policy) or after we translate the template (execute a
SQL query) completely dominates the performance profile.
So yes, let's optimize for the best-case translation when we can,
but let's not let that constrain what feature we deliver.
Templated strings can have a awful performance model if we are not
careful, and i don't think that relying on the user being careful aka
the C++ strategy is a good strategy.
They have been enough lengthy discussions about the performance of
String.format() vs StringBuilder, i think it's reasonable to avoid to
create new performance pot holes when designing this feature.
So static validation and being indy-based are a little more than just
nice to have, they are here to provide an easy to understand
performance model.
regards,
Rémi
