мне говорят что копи на кейс классе это мутация кейс класса

беги оттуда.

++

позади только заград отряды ребята

Линзы подключи и не пиши сотни вложеныъ копи; квикленс

НЕЛЬЗЯ ВООБЩЕ КОПИ ПИСАТЬ! ПОНИМАЕШЬ ЖИ!!!1!

Поцоны, имутабельность нарушена, все в хаскель

?

не да

позади только заград отряды ребята

Ты уже там работаешь что ли?

лол

очень смешная история, но не я нанимал себе коллег

Поцоны, имутабельность нарушена, все в хаскель

?

а этот спор возник после предложения воткнуть таки линзы

один назвал меня хаскелистом, второй доказывает что копи это мутабельность

надеюсь тебе хорошо платят.

Ну не хотят линзы, пересоздай кейзклксс

Типа обновить поле объекта быстрее чем сделать копи

конечно обновить поле быстрее, но ты нарушаешь тем самым свою любимую иммутабельность

вообще от задачи зависит

если не хочешь ебли с gc, то мутабельность должна быть тобой любимее)

ну блин задача изменить поле КЕЙС КЛАССА

что значит от задачи зависит?

Копи плохо делать ток потому что , сколько полку меняешь, столько и копий создаёшь временных

ну блин задача изменить поле КЕЙС КЛАССА

Там var в определении нет? Если есть вар, то скала генерит сеттер вроде бы.

Пересоздай кейзкласс

то и значит, если есть требования к латенси, то скорее всего про иммутабельность ты забудешь)

А как же jit?

ну блин задача изменить поле КЕЙС КЛАССА

изменить = мутировать, тогда там var должен быть

ну блин задача изменить поле КЕЙС КЛАССА

в целом copy это наоборот best practice, если конечно там не надо deep copy делать)

то и значит, если есть требования к латенси, то скорее всего про иммутабельность ты забудешь)

это да) даже garbage first не спасет, если требования адовые)

А как же jit?

причем тут jit

это да) даже garbage first не спасет, если требования адовые)

g1 вообще какашка для low latency)

обычный serial рулит!

то и значит, если есть требования к латенси, то скорее всего про иммутабельность ты забудешь)

еще и не просто про иммутабельность можешь забыть, а и вспомнить про view подход, когда на кусок памяти под разными углами смотришь и только оффсеты хранишь)

еще и не просто про иммутабельность можешь забыть, а и вспомнить про view подход, когда на кусок памяти под разными углами смотришь и только оффсеты хранишь)

скорее там просто будет offheap

это да) даже garbage first не спасет, если требования адовые)

если требования к латенси, то вообще про языки с гц надо забыть

если требования к латенси, то вообще про языки с гц надо забыть

не правда

ну вдруг stop the world

а у тебя требования

и что

не плоди мусор, не будет sw

тогда зачем тебе гц если у тебя мусора нет

мне? незачем

если требования к латенси, то вообще про языки с гц надо забыть

кейсы всякие бывают. бывает что надо просто все в память засунуть и выщичать не требуется и латенси у тебя будет и гц нечего собирать

но писать на джаве проще чем на крестах

лучше уж иметь sw, чем segfault )

но писать на джаве проще чем на крестах

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

угу, или обманывать себя, писать офхип, но в яве.

с с++14 очень приятно стало

но геморрой со сборкой на разных платформах все равно огребаю(

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

c++ сильно сложный стал, еще и баги в gcc бывают не приятные

поэтому лучше java взять, где хотя бы тестируют все)

угу, или обманывать себя, писать офхип, но в яве.

ждем панамку для этого)

не хорошо так делать

сча скрин дам

типа вот это вот плохо

а вот это тоже плохо но только меньше памяти жрет

классно да

а вот это тоже плохо но только меньше памяти жрет

почему меньше памяти жрет?

меньше мусора генерирует

О, среди нас Спаркист, все в Кафку

не хорошо так делать

Про память. У вас реально такие требования или просто коллегам не нравится, лишние, по их мнению, аллокации? Если второе то скажи им про преждевременную оптимизацию. Мол когда перестанет хватать памяти, будем заниматься мутациями.

это второй вопрос) стоит учитывать, что RDD lazy, поэтому map'ы там происходят sequentially, а значит аллоцируемые обьекты не уходят из eden space. Вчера же только обсуждали с Option'ами

экономия на спичках имхо. Пока это не стало ботлнеком - нет смысла делать преждевременные оптимизации.

Только там нет лоу латенси задачи в Спарке же

Про память. У вас реально такие требования или просто коллегам не нравится, лишние, по их мнению, аллокации? Если второе то скажи им про преждевременную оптимизацию. Мол когда перестанет хватать памяти, будем заниматься мутациями.

а вот эт хуевое утверждение, которые позволяте быдлокодить)

Только после map все равно же аллокация идет ?

Только там нет лоу латенси задачи в Спарке же

тем не менее есть ограничение по памяти всеж)

тем не менее есть ограничение по памяти всеж)

Есть конечно, тут с тем же успехом можно сделать class { var name = _ }

в случае RDD можно делать setName

но опять же, я бы сделал immutable data)

а вот эт хуевое утверждение, которые позволяте быдлокодить)

Все что угодно позволяет быдлокодить.

а вот эт хуевое утверждение, которые позволяте быдлокодить)

define «быдлокодить», (в данном контексте) плз

define «быдлокодить», (в данном контексте) плз

Писать на scala не так как автор утверждения

Причём автор утверждения мутабельный

define «быдлокодить», (в данном контексте) плз

программирование позволяет быдлокодить, давайте запретим программировать, да

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

Все что угодно позволяет быдлокодить.

лучше сразу подумать о тривиальных оптимизациях

Причём автор утверждения мутабельный

давайте его завернем в монадку

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

да нет же, нужно подумать изначально о структурах, может быть архитектуре и т.д

лучше сразу подумать о тривиальных оптимизациях

можно и умножение сразу вручную на сдвигах писать, но зачем?

можно и умножение сразу вручную на сдвигах писать, но зачем?

эт не тривильная оптимизация

сейчас господа

я ссылку дам на занимательное видео

https://www.youtube.com/watch?v=LEHlxHRg_bk&index=1&list=PLVe-2wcL84b-vNYciZHVDYwrOhpQRE-DT

не благодарите

сам тоже пересмотри

сам тоже пересмотри

зачем?

а то твои комментарии не особо с мыслью доклада сочетаются (хоть и не противоречат)

да нет же, нужно подумать изначально о структурах, может быть архитектуре и т.д

Можно изначально подумать о том, что лучше бы сделать юникернел, что бы не тратиться на сисколы из юзерспейса. Можно изначально подумать, что GC жрет ресурсы и можно управлять памятью ручками. Можно заранее подумать о чем угодно.

а то твои комментарии не особо с мыслью доклада сочетаются (хоть и не противоречат)

чувак, моя мысль проста) что то утверждение про преждевременную оптимизацию хуиня, вот и все)

Потому что у "тривиальности" нет границ.

чувак, моя мысль проста) что то утверждение про преждевременную оптимизацию хуиня, вот и все)

вот это и не пересекается с докладом

Потому что у "тривиальности" нет границ.

таки это задача про два стула)

вот это и не пересекается с докладом

в чем?

чувак, моя мысль проста) что то утверждение про преждевременную оптимизацию хуиня, вот и все)

Не хуйня. Предже чем что-то оптимизировать, это что-то надо измерить.

доклад о рациональной трате ресурсов на вопрос производительности