Pull to refresh

Comments 33

И даже на меня не сослался :( Я в печали. А ведь я как раз на опыте домклика (в основном) делал свой доклад про котлин в проде.

А оказывается просто не в этой части будет про меня. Тогда никаких обид.

Интересно бы увидеть таблицу для разных компиляторов (и их версий) для компиляции HelloWorld
В которой будет количество Mb прочитанных с диска, использованной памяти, и общего времени выполнения.
Что-то подсказывает groovy, kotlin и rust будут в «лидерах» по КПД.
21+
Вызов компилятора kotlinc из командной строки 6сек тот же swift 0.1сек.
Ладно что большую часть это загрузка java rt.jar 62Mb на любой вызов.
Но писать результирующие файлы по 1 байту за раз ???

image

Спасибо за репорт, пошёл спрашивать у коллег.

Пишет если сделать так, чтобы писал. Я не думал что этим кто-то пользуется и никогда не пользовался сам, но…

Что-то подсказывает groovy, kotlin и rust будут в «лидерах» по КПД.
Не думаю, что кто-то сможет обогнать C++ :)
А так, HelloWorld измерять бессмысленно, надо что-то реалистичное. А то это выглядит как «Попробуем перевезти мешок картошки на оке и белазе. Очевидно, у белаза, самый фиговый КПД, выводы делайте сами».
Для тех кто в танке специально кавычки поставил. Даже C++ не выполняет столько бесполезной работы что бы скомпилировать hello world (пока не подключишь немного boost-а)
ps: В эту же кучу еще надо отправить компилятор cuda который выполняет под капотом много чего что вызывает вопросы. (просто по наблюдайте за тем что появляется в директории %temp% пока оно компилирует)
Даже C++ не выполняет столько бесполезной работы что бы скомпилировать hello world
Опять же к вопросу, как часто вы компилируете «hello world»? Это искусственная задача, в которой полезной работы исчезающе мало, по сравнению с ней любые накладные расходы будут «огромными».

Как и обещал, возвращаюсь с ответом.
Спасибо большое что сообщили о проблеме, мы завели по поводу её тикет https://youtrack.jetbrains.com/issue/KT-38176
Не уверен что она будет исправлена прямо совсем скоро — всё-таки создание jar-файлов из kotlinc совсем нечастая операция и ни одна из поддерживаемых билд систем её не использует, однако же это не значит что она не должна быть исправлена.


Ещё раз большое спасибо за репорт.

А почему бы и нет
new BufferedOutputStream(new FileOutputStream(...

Ну мне тоже так кажется, но в принципе вы можете попробовать сделать PR с этим исправлением. А если ещё и бенчмарк будет там — то вообще офигенно.

Только вот на винде не выполнится )))

Под виндой можно например так:

// test.c
#include <time.h>
#include <stdio.h>
#include <process.h>

int main(int argc, char const *argv[]) {
  int i; FILE *f; double dt; clock_t c1,c2;
  enum { N=5 };

  f=fopen("test.kt","w+b"); if (!f) return 1;
  fprintf(f,"fun main() {\n"
    "  println(\"hello kotlin\")\n" 
    "}\n");
  fclose(f);

  for(i=1;i<=N;++i) { 
    c1=clock();
    if (system("kotlinc test.kt -include-runtime -d test.jar")) return 2;
    c2=clock();
    dt=c2-c1; dt/=CLOCKS_PER_SEC;
    printf("%d\t%.2f sec\n",i,dt);
  }

  return 0;
}

tcc test.c && test
Автогенерируемые прекондишены когда можно будет отключать? Из-за них дорога котлина в интерпрайз будет закрыта.
Потому, что их нельзя отключить. А это причина №1 почему миграция на котлин откладывается. Производительность приложения после миграции с java падает в 50-100 раз. Надо очень много допиливать ручками.

Не может быть что из-за проверок на нал падает. Они джитом должны выпиливаться. Однако же если вы уверены что проблема именно в них, то есть -Xno-param-assertions -Xno-receiver-assertions

Да, вот именно их и не хватало. Надо будет заново протестить миграцию.

Они были как минимум с версии 1.1, вы просто не очень внимательно прочитали хелп.

Пожалуйста, дайте ссылку на официальную доку по этим параметрам.

Я, честно говоря, не знаю, есть ли дока по аргументам kotlinc, но узнать про все существующие параметры можно с помощью -help и -X -help, так же как в случае с javac

Если можно, очень хотелось бы посмотреть на код бенчмарков и какой-нибудь минимально воспроизводимый пример. Потому что если существует какой-то кейс, при котором проверки на налл реально тормозят находясь на горячем пути — мне бы очень хотелось о них знать.


То, с чем я встречался — это что java2kotin генерирует неоптимальный код, но с этим особо ничего не сделаешь — оптимальный код доменно-специфичен.

При помощи Kotlin MPP вы можете использовать Kotlin как дефолтный язык в разработке в своей компании.

Можно ли это делать без знаний Java и её экосистемы в компании? Не получится ли, что компания (или отдельный разработчик), решившие сделать для себя Kotlin дефолтным язык в итоге 80+% времени потратят на изучении и внедрение не Kotlin, а Java? Что, грубо говоря, отдельный Kotlin-разработчик, никогда на Java не писавший, уже на 90% Java-разработчик?


P.S. Кстати, есть какие-то книги, курсы и т. п. по обучению разработки на kotlin, не подразумевающие знания Java? Или как 90+% книг и курсов на TypeScript: "Typescript — это JavaScript, но с типами. Вот эти типы мы и будем изучать в рамках этого курса"

Ну не 80%, но немного потратят. У меня как раз есть опыт работы с kotlin на бэкенде без знания java. Сам котлин и его фишечки с корутинами и каналами как в Go очень приятные.
Код получается лаконичный. Но когда нет опыта с java world, случаются нежданчики.

Ставишь простой с виду логгер. А как его тюнить — хз, нет опции в конструкторе типа «конфиг». Потом оказывается, что нужен как-то xml файл с конфигом для логов «как обычно». И начинаешь гуглить, как так получилось, что логгер который «чисто на котлине», на самом деле обертка над оберткой и еще над оберткой, и почему ему нужен какой-то xml конфиг в каком-то правильном месте.
Для тех, кто с java знаком, тем все очевидно.
Или работа с датой временем. Есть joda.Time, есть еще java.Time. И если какая-то сторонняя либа использует только joda.Time, а ты везде используешь jave.Time, то пиши переходник. И поначалу непонятно, какого огурца вообще происходит и зачем нужны 2 либы для работы со временем.

Это все нюансы java world, которых там много, но их как-то быстро преодолеваешь и потом нормально.

Kotlin MPP связан с джава экосистемой примерно никак. Стандартной библиотеки джавовой в нём нет, по сути только базовые типы. Остальное можно добрать сторонними библиотеками.

А как насчёт управления библиотеками (пакетными менеджерами), системами сборки, вон про конфигурирование выше пишут, особенно в случае использовании для классического HTTP REST бэкенда

Управление библиотеками, сборкой, тестами — gradle. Но писать бэкэнд на MPP кажется странным, как раз тут лучше получится обычный Kotlin/JVM, мне кажется.

Я в разнице не разбираюсь. Что в статье написано, то и процитировал :) Может там что-то имелось в виду типа "на фронте/мобайле Kotlin MPP, а на бэке "голый" Kotlin", но сути моего вопрос это не меняяет: если взять фулстека, который существующий стэк (пускай PHP+TS) переводит на Kotlin MPP/Kotlin, то не получится ли, что 80+ % времени он будет заниматься по факту изучением Java и её экосистемы, а лишь 20%- собственно Kotlin

О, такого опыта у меня нет, к сожалению, не буду комментировать.

Sign up to leave a comment.