On Sat, 27 Jul 2024 23:08:36 GMT, Shaojin Wen <d...@openjdk.org> wrote:
> Should mixer and prepend add the two types of Integer and Long? Now we need > to do integer.toString and then concatenate, which leads to performance > degradation. I think the generic problem with specializing on types is that this leads to a exponential explosion in the upper bound of classes which can be generated. Currently `concat_expr + Object`, `concat_expr + Integer`, `concat_expr + Long` all get translated into a single implementation class (which stringifies the argument up front in a generic way). If we specialize we'd get a new set of distinct implementation classes any time there's any combination of `Integer` or `Long`. Of course for the very high arity expressions where we are already specializing for the exact expression then specializing as precisely as we can does not cause an influx in new classes. So it might make sense here, but needs more data. For the very high-arity expressions I think the added cost of the extra `toString`s is likely negligible, though. Let's think about the trade-offs: by default we need something that makes sure low-arity expressions can be reasonably shared, otherwise even smallish apps might see thousands of excess classes generated to support string concatenation. But if we don't share, we can specialize precisely. So it might turn out we can produce something that optimizes better when specializing precisely and creating a class at the call site. What value the threshold should have then becomes an interesting question (which I know you asked elsewhere). Right now it's set pretty high simply because the current high-arity implementation is decidedly worse than the MH-based one. With this PR it gets an equal footing. So perhaps it should be lowered. (But let's defer that decision to a separate PR.) With deeper specialization (optimizing for `Integer`, `Long`, `StringBuilder` etc arguments) the implementations could hypothetically become a bit faster. It might make sense to apply such optimizations to either the high-arity translation, or both. The decision to specialize and the threshold then becomes a classic space-time trade-off tuning decision: OK to generate more classes which has a chance at optimizing significantly better? Lower the threshold/specialize deeper. Save space, get faster startup and shorter warmup, but perhaps lose a few percent raw performance? Raise the threshold/disable specialization. I think these are interesting questions, but I don't think we should rush into this. Let's wean us off the MH-based implementation first. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2254463494
