Здравствуйте, Serginio1, Вы писали:

S>>> В том чиле и метод. Это касается прежде всего int, byte, Int64 где вызов метода 1+1, значительно дольше самого сложения, сравнения
S>·>Что "метод"? Имплементировать интерфейс — значит написать имплементацию метода(ов) этого интерфейса. После девиртуализации вызова Comparator.compare станет доступным тело метода для инлайнинга.
S> Вот кстати для примера посмотри на stackalloc для классов и какое оно дает ускорение.
S>http://xoofx.com/blog/2015/10/08/stackalloc-for-class-with-roslyn-and-coreclr/
ну опять же "ускорение по сравнению с dotnet" же. В Яве же есть escape analysis, который может разместить объект на стеке, если объект не покидает некий scope.

S>>> Для мобильных платформ там совсем другие VM.
S>·>И что? Они медленнее .net что-ли?
S> Не знаю. Я лишь, говорю о том, что .Net Native может использовать более продвинутую компиляцию в машинный код
S>и не зависит от установленного .Net Core
Так java тоже может использовать.

S>·>Что? Почему? Ты о чём?
S> Я про мобильные устройства говорю, а ты мне ссылки для декстопа.
Какие ссылки для десктопа? Я говорю, что идея компилировать в натив-бинарники для девайсов на серверах магазина — плохомасштабируемая идея. Это ещё может работать для Яблок, их всего около десятка версий, притом только две-три активные. А для андроида — упс.

S>>>·>https://www.excelsior-usa.com/jetdladdon.php?jetversion=700
S>>> А где Андроид? Мы то говорим про мобильные платформы. .Net Native выгоден прежде всего для мобильных устройств.
S>·>Так для андроида ART есть, я же говорил уже, можно тупо локально dex2oat запускать для генерации бинарика.
S> Еще раз это аналог .NGEN. Он мало, что дает. И оптимизации для андроид версии там скорее всего нет, ибо батарея будет садиться быстро.
.net native делается с целью убрать зависимость от fw (который изначально был непереносимым и неотъемлимым компонентом системы, засунутый по самые гланды), а производительность за счёт чего? (ну кроме как за счёт исправления косяков ngen).
Цели убрать такую зависимость в ART нет, поэтому сделали именно так.
Компиляторы java->native были, есть и будут если понадобится. Каких-то принципиальных проблем их использовать — нет.

Я, кстати, много лет назад использовал GCJ, чтобы собрать из java-кода standalone (в смысле без каких либо зависимостей) dll.