KD
Не юзал компоуз, но вот эта дрянь с
@Composable жутко раздражает.В двух словах, а в чём была проблема отказаться от магии и сделать всё, пусть несколько сложнее в юзабилити, но куда более явным?
Size: a a a
2020 November 17
BP
И этот человек пишет приложение, которое должно выдавать кадр за 33 мс.
Помню так говорили сппшники, что джава тормозит, объект там дорого выделить и и.д.
ML
В двух словах, а в чём была проблема отказаться от магии и сделать всё, пусть несколько сложнее в юзабилити, но куда более явным?
тем, что для текущей концепции тебе бы пришлось каждый вызов if/when оборачивать в лямбду и предоставлять ей уникальный id
KD
тем, что для текущей концепции тебе бы пришлось каждый вызов if/when оборачивать в лямбду и предоставлять ей уникальный id
Может тогда проблема в изначально выбранной концепции?
BP
Почему я не удивлён, что Скобка предлагает выделять память на каждый чих...
Ты хотел сказать: Почему новый скоуп/корутина создаётся на каждый чих
ML
Может тогда проблема в изначально выбранной концепции?
ну тут вопрос терйд-оффов. Лично мне концепция "всё есть хуки" и мемоизация побочных эффектов нравится больше. Она ближе к железу, при этом сохраняет самые важные плюшки аналогичных фреймворков
BP
Иначе никак. Для гуёвых приложений с ГЦ, ГЦ оптимизируют на минимизацию пауз сборки мусора. Взамен ГЦ требует кучу рамы. Rosaalloc (ЕМНИП, так называется андроидовский сборщик мусора) очень прожорлив по памяти, но лучше того, что был в дальвике по паузам. Пока шанонду не портируют на ведро, не выделять память - выигрышная стратегия. К счастью, гугл, в отличие от Скобки, это прекрасно понимает.
Согласен, но ваш же язык очень много срет объектами, идеяйка все больше есть рамы. Так что давайте тогда и вы свои приложения подтяните, тулбокс 150 мб - это капец
I
Ты хотел сказать: Почему новый скоуп/корутина создаётся на каждый чих
Будем считать, что я заглотил наживку. Три слова - tail-call optimization & crossinline. Если бы на аллокации было насрать, то ничего из этого не было бы.
I
Согласен, но ваш же язык очень много срет объектами, идеяйка все больше есть рамы. Так что давайте тогда и вы свои приложения подтяните, тулбокс 150 мб - это капец
Дядя, ты калитку не попутал?
с#
Согласен, но ваш же язык очень много срет объектами, идеяйка все больше есть рамы. Так что давайте тогда и вы свои приложения подтяните, тулбокс 150 мб - это капец
тулбокс на электроне, isn't it ?
KD
ну тут вопрос терйд-оффов. Лично мне концепция "всё есть хуки" и мемоизация побочных эффектов нравится больше. Она ближе к железу, при этом сохраняет самые важные плюшки аналогичных фреймворков
Я не особо в контексте. Что здесь есть "хуки"?
I
тулбокс на электроне, isn't it ?
Ну формально там jvm и chromium
BP
тулбокс на электроне, isn't it ?
Нет на qt, но там webview
ML
Я не особо в контексте. Что здесь есть "хуки"?
функции, которые будут вызваны если изменится execution path
ML
либо их результат будет переиспользован если ничего не изменилось
ML
Я не особо в контексте. Что здесь есть "хуки"?
BP
Дядя, ты калитку не попутал?
Ну так ты сам говоришь что нужно алокации в ui беречь, давайка мы пойдем делать плагин и посчитаем сколько билдеров создаёт ваш api
I
Нет на qt, но там webview
Это старая версию, там уже больше года, как переписали на kotlin-jvm + CEF
KD
функции, которые будут вызваны если изменится execution path
Т.е., вся эта магия с
Просто, чтобы не перевызывать лямбды\функции по сто раз?
@Composable сделана лишь для оптимизации отрисовки?Просто, чтобы не перевызывать лямбды\функции по сто раз?
ML
Т.е., вся эта магия с
Просто, чтобы не перевызывать лямбды\функции по сто раз?
@Composable сделана лишь для оптимизации отрисовки?Просто, чтобы не перевызывать лямбды\функции по сто раз?
да